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VORWORT 


Mit diesem Band wird unter dem Titel "Programmiersprachen im 
Griff" eine Reihe von Lehrbüchern über die bekanntesten Pro¬ 
grammiersprachen in einheitlicher Gliederung, Gestaltung und 
Terminologie fortgesetzt. 

In diese Reihe gehen Erfahrungen ein, die wir in den letzten 
Jahren bei der Abhaltung von Vorlesungen über Programmieren 
für Hörer aller Fachrichtungen an der Universität Karlsruhe, 
sowie in Seminaren und Arbeitskreisen über höhere Program¬ 
miersprachen gewonnen haben. Die Erfahrungen haben gezeigt, 
daß ein wirkungsvolles Ausbilden und Erlernen nur möglich 
ist, wenn die Programmiersprachen einheitlich, übersichtlich 
und einprägsam dargesteilt werden. Dies wird erreicht durch 
die Darstellung der Syntax der Sprachen in einer standardi¬ 
sierten Syntaxdiagrammform und einer darauf abgestimmten Be¬ 
schreibung der Semantik. Dem Zweck dieser Reihe entsprechend 
sind die folgenden Punkte besonders berücksichtigt: 

- Vollständige Wiedergabe des Inhaltes der jeweiligen origi¬ 
nalen Sprachbeschreibungen. 

- Einheitliche Darstellung der Syntax, die insbesondere 
durch den Aufbau der Diagramme, deren Bezeichungsweisen, 
die Wahl der Kommentare usw. erzielt wird. 

- Einheitliche Beschreibungsart der Semantik, insbesondere 
durch Verwendung gleicher Begriffe, Ausdrucksweisen usw. 

- Einarbeitung von Semantikhinweisen in die Syntaxdiagramme 
zur schnellen Erfassung des Sprachelementes. 

- Didaktische Aufbereitung des Stoffes durch den linearen 
Aufbau von einfachen Sprachelementen bis zum komplizierten 
Programm. 

- Angabe von instruktiven Beispielen. 

- Ausführliche Register. 
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Damit eignet sich jedes Buch dieser Reihe unmittelbar als 
Vorlesungsmanuskript und dient auch dem Neuling bestens als 
Leitfaden für das Erlernen der beschriebenen Programmierspra¬ 
che. Trotz der didaktischen Aufbereitung ist jeweils der vol¬ 
le Sprachumfang wiedergegeben. 

Der hier vorliegende Band ist in sich abgeschlossen und kann 
ohne weitere Voraussetzungen gelesen werden. Die Einarbeitung 
in die Materie wird jedoch deutlich erleichtert, wenn Kennt¬ 
nisse in höheren Programmiersprachen, insbesondere von PAS¬ 
CAL, vorliegen. Um den Rahmen nicht zu sprengen, sind alle 
Beispiele nur exemplarisch zu verstehen und erheben keinen 
Anspruch auf Vollständigkeit, Optimalität, usw. Insbesondere 
wird aus Platzgründen auf Flußdiagramme völlig verzichtet. 

Unser Dank gilt allen, die zum Gelingen dieses Buches - sei 
es durch Diskussionen oder durch das Austesten von Program¬ 
men - bei getragen haben, insbesondere den Herren cand. math. 
Martin Hanke, cand. math. Torsten Rössel, cand. math. Günter 
Schumacher sowie Herrn Dipl. Math. Werner Frangen. 

Wir danken Herrn Prof. Dr. Ulrich Kulisch, der das Entstehen 
dieses Buches ermöglicht hat, und dem Bibliographischen In¬ 
stitut für die Aufnahme dieses Buches in die Reihe "Hoch¬ 
schul taschenbücher". 

Besondere Anerkennung verdient Frl. Dipl. Math. Margit Bür- 
zele, die nicht nur mit großer Sorgfalt die mühevolle Nieder¬ 
schrift des Manuskriptes besorgte, sondern auch alle Diagram¬ 
me in die perfekte Form gebracht hat. 


Karlsruhe, Oktober 1982 


Die Verfasser 
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A. EINLEITUNG 


A. EINLEITUNG 


Einführende Bemerkungen zu Sinn und Zweck des Programmierens, 
zur Problemanalyse und -algorithmisierung, sowie zur Entwick¬ 
lungsgeschichte, Aufbau und Wirkungsweise elektronischer Re¬ 
chenanlagen würden den Rahmen dieses Buches sprengen. Sie 
können ohne weiteres in anderen Bänden der Reihe nachgelesen 
werden. 


1. PROGRAMMIERSPRACHEN - EIN KURZER ÜBERBLICK 


Es ist üblich geworden, drei Arten von Programmiersprachen zu 
unterscheiden: 

Maschinensprachen, 

maschinenorientierte oder einfache Programmiersprachen 
(Assemblersprachen), 

problemorientierte oder höhere Programmiersprachen. 
Maschinensprachen 

Jeder Rechenautomat besitzt eine Programmiersprache, die er 
unmittelbar "lesen" und ohne menschliche Hilfe in Steuer¬ 
signale umsetzen kann. Sie ist durch seine Bauart festgelegt 
und i.a. nicht auf Rechner anderen Typs übertragbar. Man 
bezeichnet sie deshalb auch als Maschinensprache und ein in 
ihr geschriebenes Programm als Maschi nenpro- 
g r a m m . 

Der Gebrauch von Maschinenprogrammen hat zwei große Nachtei¬ 
le. Einmal muß der Programmierer für jeden Maschinentyp eine 



1. Programmiersprachen Überblick 
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eigene Sprache erlernen, zum anderen benutzen Maschinenspra¬ 
chen fast stets eine Ziffernverschlüsselung. Ein Maschinen¬ 
programm ist deshalb nicht sehr übersichtlich, erfordert aber 
zu seiner Herstellung ungewöhnlich viel Zeit und Konzentra¬ 
tion. Man hat aus diesen Gründen nach Möglichkeiten gesucht, 
das Programmieren durch Entwicklung einfacherer Sprachen zu 
erleichtern. 

Assemblersprachen (maschinenorientierte Programmiersprachen) 

Diese Sprachen benutzen für die einzelnen Rechenoperationen 
statt einer Ziffernverschlüsselung mnemotechnische Abkürzun¬ 
gen, die sich leicht merken lassen (z.B. mul für Multiplika¬ 
tion); außerdem machen sie Gebrauch von der sog. symbolischen 
Adressierung, wodurch das Programmieren ganz wesentlich er¬ 
leichtert wird, und schließlich verwenden sie für den Aufruf 
häufig vorkommender Unterprogramme sog. Makrobefehle. Sie 
sind aber sonst den Maschinensprachen noch sehr verwandt, und 
ihre Anwendung führt nicht zu einer wesentlichen Verkürzung 
der Programme. 

Problemorientierte Programmiersprachen 

Gegenüber den Assemblersprachen sind die problemorientierten 
Programmiersprachen nicht an einen bestimmten Rechnertyp ge¬ 
bunden. Sie verwenden in weitem Maße gebräuchliche mathemati¬ 
sche Schreibweisen und lassen sich deshalb besonders leicht 
erlernen. Zudem verzichten sie fast ganz auf die für das Pro¬ 
grammieren so lästigen maschineninternen Operationen, wie 
z.B. Datentransportvorgänge, die für das eigentliche mathema¬ 
tische Problem gar keine Bedeutung haben. Deshalb nennt man 
solche Sprachen auch "problemorientiert". 

Zur Programmierung mathematischer, naturwissenschaftlieher 
und technischer Probleme haben u.a. folgende problemorien¬ 
tierte Sprachen weite Verbreitung gefunden: 
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A. EINLEITUNG 


ALGOL 60 (ALGOrithmic Language) 

Die Sprache wurde in Europa gemeinsam von vielen wissen¬ 
schaftlichen Institutionen aus 6 Ländern entwickelt und 
1960 publiziert ([28]). 

BASIC (Beginners All-purpose Symbolic Instruction Code) 

Ein vereinfachtes, FORTRAN-ähnliches Programmiersystem, be¬ 
sonders auf Kleinrechnern verbreitet. Die Entwicklung ging 
1960 von J. Kemmeny und Th. Kurtz aus ([31]). 

COBOL (COmmon Business Orientated Language) 

Die Sprache ist vorwiegend den Bedürfnissen einer kommer¬ 
ziellen Datenverarbeitung angepaßt und erlaubt in einfacher 
Weise den Umgang mit großen Datenmengen. Sie wurde 1959 in 
den USA entwickelt, 1961 erstmals publiziert und seither wie¬ 
derholt überarbeitet ([39]). 

FORTRAN (FORmula TRANslation) 

FORTRAN wurde 1954 als erste problemorientierte Programmier¬ 
sprache von J. W. Backus entworfen, in den USA in mehreren 
Versionen weiterentwickelt und liegt zur Zeit in dem Standard 
FORTRAN 77 vor ([29]). 

PASCAL 

Eine ALGOL-ähnliche, von K. Jensen und N. Wirth Anfang der 
70er Jahre entwickelte Programmiersprache mit erweitertem 
Typ-, Ausdrucks- und Anweisungskonzept. Zwischenzeitlich ent¬ 
standen auch hier dem modernsten Stand der Wissenschaft an¬ 
gepaßte Versionen, wie z.B. Matrix PASCAL ([17],[18],[30]). 

ADA 

ADA wurde im Rahmen eines Wettbewerbes des amerikanischen 
Verteidigungsministeriums entwickelt ([1]). Es soll durch 
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seine universelle Einsetzbarkeit sowohl im kommerziellen als 
auch technisch wissenschaftlichen Bereich dazu dienen, die 
Wartungskosten für Software möglichst gering zu halten. Ein 
ADA-Programm wird in der Regel auf einem (großen) Rechner 
entwickelt und getestet und kommt dann auf anderen (kleinen) 
Rechnern zum Einsatz. ADA ermöglicht einen modularen Aufbau 
der Programme und getrennte Übersetzung der einzelnen Mo¬ 
duln, dies allerdings bei klarer Definition und Überprüfung 
der Schnittstellen. Zur Modularisierung stehen Unterprogram¬ 
me, Pakete und Prozesse zur Verfügung. Pakete fassen zusam¬ 
menhängende Daten und Operationen zusammen. Prozesse ermög¬ 
lichen die parallele Verarbeitung. 
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A. EINLEITUNG 


2. DARSTELLUNG HÖHERER PROGRAMMIERSPRACHEN 


Die Festlegung einer höheren Programmiersprache erfolgt ge¬ 
wöhnlich durch vier Komponenten: 

Alphabet 

Syntax 

Semantik 

Pragmatik. 


2,1 ALPHABET 

Grundlage einer jeden Programmiersprache ist ein Symbol Vor¬ 
rat, das sogenannte Al phabet. Mit diesen Symbolen 
werden Programme dargestellt. Da i.a. nicht jede Symbol folge 
als Programm zugelassen werden soll, bedarf es einer Vor¬ 
schrift, welche die zulässigen Symbol folgen auswählt. Als 
Alphabet der deutschen Sprache kann man z.B. alle im Duden 
aufgelisteten Wörter und Satzzeichen ansehen. 


2,2 SYNTAX 

Die Syntax regelt, welche Symbol folgen des zugrunde¬ 
gelegten Vokabulars (Alphabets) zulässige "Sätze" ( P r o - 
g r a m m e ) der Sprache bilden und legt gleichzeitig zu 
jeder solchen Symbol folge eine grammatikalische Struktur 
fest. 

Wir machen uns dies an einem Beispiel der deutschen Sprache 
klar: 

Der Satz: "Der Floh beißt den Hund" wird gemäß folgender 
Tabelle in Sprachelemente zerlegt: 


2.2 Syntax 
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Satzteil 


grammatikalische Bezeichnung 


Der Floh 
beißt 
den Hund 


Subjekt 

Prädikat 

Objekt 


Entsprechend dieser Zerlegung von natürlichen Sprachen wer¬ 
den auch Programmiersprachen in grammatikalische Bestandtei¬ 
le gegliedert. 

Für die Beschreibung der Syntax werden hier Syntaxdiagramme 
verwendet. 

2.2.1 ELEMENTARE SYNTAXDIAGRAMME 

Die Gestaltung dieser Diagramme wird in folgender Weise vor¬ 
genommen: 

- Jedes Diagramm besitzt einen oder mehrere (grammatikali¬ 
sche) Bezei chner, welche in Großbuchstaben ge¬ 
schrieben und links über das betreffende Diagramm gesetzt 
sind. Die Bezeichner sind stets so gewählt, daß sie einen 
Hinweis auf das durch das Diagramm dargestellte Sprachele- 
ment enthalten. 

- Ein Diagramm ist aufgebaut aus Bezeichnern von Diagram¬ 
men, Symbolen des Alphabets und durchgezogenen bzw. ge¬ 
punkteten Linien. 

- Ein Symbol des AlpkabeÄA ist in einen Kreis eingeschlos¬ 
sen bzw. als Wortsymbol unterstrichen. Folgen von Symbo¬ 
len sind in ein Oval eingeschlossen. 

- Die Verbindung von Bezeichnern und Symbolen des Alphabets 
geschieht durch durchgezogene bzw. gepunktete Linien. 

- Stehen über einem Syntaxdiagramm mehrere Bezeichner, so 


2 Kaucher IV - ADA 
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A. EINLEITUNG 


bedeutet dies für alle darliberstehenden Bezeichner den 
gleichen syntaktischen Aufbau. 

- Die Diagramme sind durchnumeriert. 
z.B. bedeutet 

ADA 65: NAME 
MARKE 

daß die Bezeichner NAME und MARKE das gemeinsame Dia¬ 
gramm mit der Nummer 65 haben, d.h. syntaktisch gleich 
aufgebaut sind. 

- Die Diagramme sind mit in Kursivschrift geschriebenen er¬ 
läuternden Kommentaren versehen. Sie erleichtern das se¬ 
mantische Erfassen des betreffenden Sprachelementes und 
sind entweder unter, neben oder auch über der entsprechen¬ 
den Diagrammzeile angebracht. 

- Am Schluß wird eine Liste aller vorkommenden Bezeichner 
in alphabetischer Anordnung gegeben, die das Auffinden 
der zugehörigen Diagramme erleichtert ( siehe D.l). 

Die Verwendung der Syntaxdiagramme zum Schreiben von Pro¬ 
grammen geschieht in der folgenden Weise: 

- Der Vusicklaufi eines Diagrammes beginnt am lin¬ 
ken oberen Eingang. 

- Durchgezogene Linien werden von links nach rechts bzw. 
von oben nach unten, gepunktete Linien in umgekehrter 
Richtung du.fic.klau 62 .n . 

- Der Vusicklaufi eines Diagrammes ist beendet, 
wenn das Diagramm am rechten unteren Ende verlassen wird. 

- Treten beim Vusicktaufi eines Diagrammes Symbole 
des Alphabets A auf, so werden diese zum Zeitpunkt des 
Auftretens notiert und der DuAcklau^ fortgesetzt. 

- Tritt beim Vusich.lau .6 eines Diagrammes <j> eine 
Syntaxvariable ip auf (wobei ip gleich (p zulässig), so ist 
an dieser Stelle der VuAchlaufi von <j> zu unterbrechen, das 


2.2.1 Elementare Syntaxdiagramme 
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mit diesem Namen \p bezeichnete Diagramm zu duAcklaufizn 
und danach der VmAcklajn^ des Diagrammes <p an der Stelle 
fortzusetzen, an der er unterbrochen wurde. 

- Zur Produktion eines Programmes ist stets das mit dem 
Startbezeichner PROGRAMM versehene Diagramm zu 
dLLSLCklCLUfi&Vl. 

Grundsätzlich kann mit der oben beschriebenen Vorgehensweise 
aus dem Startbezeichner PROGRAMM ein gewünschtes Pro¬ 
gramm geschrieben werden. Dieses Vorgehen ist jedoch schwer¬ 
fällig und wird man nur zur Einarbeitung verwenden. Tatsäch¬ 
lich prägt sich der Leser durch wiederholten Gebrauch der 
Syntaxdiagramme schnell den Aufbau der einzelnen Sprachele- 
mente (Syntaxdiagramme) ein und kann somit einen in einem 
Diagramm <j> auftretenden Syntaxbezeichner ip unmittelbar durch 
die gewünschte Symbol folge bzw. einen zulässigen Diagramm¬ 
teil ersetzen, ohne zuvor ij; (und deren Folgediagramme) 
durchlaufen zu müssen. 

Beispiel: 

Mit den Diagrammen aus 

ADA 28: I AUSDRUCK 




mod 



I OPERAND 


2* 
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aus 


ADA 31: I OPERAND 


I VARIABLE - 

I KONSTANTE - 

<T>- I AUSDRUCK -®- 
-©- I AUSDRUCK —©- 


aus 


aus 


ADA 39: I KONSTANTE (I K) 

-ZF- 


ADA 33: I VARIABLE (I VAR) 

- I VAR NAME - 


aus 


ADA 65: I VAR NAME 


— BUCHSTABE ■ 


••• BUCHSTABE •• 


. ZIFFER ••• 

i”0"j 


können wir z.B. folgenden I AUSDRUCK erzeugen: 

((i + j) * k / 1 - 501) mod (-8) . 

Die Erzeugung läuft gemäß folgender Tabelle ab. 




















2.2.1 Elementare Syntaxdiagramme 
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D Nr. 

Knoten Nr. 

Sprachelement 

28 

1.4.5,4 

I OPD mod I OPD 


31 

4 

(I A) mod I OPD 


28 

1.4,7,4 

(I OPD * I OPD / I OPD - 

I OPD) mod 


6,4,8,4 

I OPD 


31 

4 

((I A) * I OPD ... 


28 

1,4,9,4 

((I OPD + I OPD) * ... 


31 

1 

((I VAR + I OPD) «... 


31 

1 

((I VAR + I VAR) * I OPD / I OPD - I OPD) 



mod I OPD 


31 

1 

((...) * I VAR / I OPD - 

I OPD) mod I OPD 

31 

1 

((...)* I VAR / I VAR - 

I OPD) mod I OPD 

31 

2 

((... 

- I K) mod I OPD 

31 

4 

((... 

mod (I A) 

28 

3,4 

((... 

mod (-1 OPD) 

31 

2 

((... 

mod (- I K) 


Unter Verwendung der Diagramme 33, 65 und 68 kann schließlich 
I VAR ersetzt werden durch i,j,k,l; mit den Diagrammen 39,56 
und 67 kann I K ersetzt werden durch 501 bzw. 8. 

Umgekehrt tritt oft das Problem auf, zu prüfen, ob ein vor¬ 
gegebenes Sprachelement grammatikalisch korrekt ist. Dabei 
ist zu versuchen, den obigen Prozeß in umgekehrter Richtung 
zu durchlaufen. Gelingt es, den zu prüfenden Ausdruck auf 
einen I AUSDRUCK zurückzuführen, so ist das Sprachelement 
korrekt, andernfalls ist es grammatikalisch unzulässig. 

Die Durchführung dieses Prozesses (Syntaxanalyse) erfordert 
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Geschick und Vertrautheit mit den Sprache!ementen. Daher ist 
es für den Programmieranfänger einfacher, das Sprache!ement 
in der zuerst beschriebenen Weise zu erzeugen. Gelingt dies, 
so ist das vorgelegte Sprachelement grammatikalisch korrekt, 
andernfalls grammatikalisch unzulässig. 

Beispiel: Ist i * - n ein korrekter I AUSDRUCK ? 


Diagramm 

Nr. 

Knoten Nr. 

Sprachelement 

28 

1,4,7,4 

I OPD * I OPD 

28 

1,4,8,4 

I OPD - I OPD 


In beiden Fällen kann der zweite Operator nicht unmittelbar 
durch Ersetzen von I OPD erzeugt werden. Dies erkennt man 
durch folgende Versuche: da in I OPD explizit weder das 
Zeichen - noch * vorkommt, ist dies höchstens über 4 
mittels I AUSDRUCK möglich. In diesem Fall müßte dann al¬ 
lerdings geklammert werden, was nicht auf den vorgegebenen 
Ausdruck führt: 

Fährt man im ersten Fall mit ADA 31,4 und ADA 28,3,4 fort, 
so ergibt sich 

i * (-n) 

bzw. im zweiten Fall mit ADA 31,4 und ADA 28,1,4,7,4 
(1*1 OPD) - n , 

d.h. das Zeichen * ist nicht allein erzeugbar. 

Im Gegensatz dazu ist jedoch 
-n * i 

grammatikalisch korrekt, wie der Leser selbst nachvollziehen 
kann. 






2.2.1 Elementare Syntaxdiagramme 
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Die arbeitsaufwendige Syntaxanalyse übernimmt die Rechenan¬ 


lage, die vor Ausführung eines 
matisch die Analyse durchführt 
sehe Konstruktionen meldet. 

Abschließend erläutern wir die 
des syntaktischen Aufbaues von 

Beispiel: 

Mit den Syntaxdiagrammen 

ADA 65: NAME 


eingegebenen Programmes auto- 
und fehlerhafte grammatikali- 

Erzeugung und das Erlernen 
Sprachelementen an folgendem 


AUSNAHME NAME 

BIBLIOTHEKS EINHEITS NAME (BIBL EINH NAME) 

BLOCKNAME (BL NAME) 

t DISKRIMINANTEN NAME (t DISKR NAME) t e o D 
ENTRY FAMILIEN NAME (ENTRY FAM NAME) 

ENTRY NAME 

T FUNKT IONS NAME (r FKT NAME) neu* 

6ERAET 

T KOMPONENTEN NAME (t KOMP NAME) t e 0 u {pzst u » 

t KONSTANTEN NAME (t KONST NAME) r e 0 

MARKE 

PAKET NAME (PAK NAME) 

PROZEDUR NAME (PZD NAME) 

SCHLEIFLN NAME (SCHL NAME) 

t TYP NAME t e 0 u (pzs) u * 

r VARIABLEN NAME (t VAR NAME) t e 0 u (pzs) u ♦ 


0 « (B.CH.AZ,{.G.F.A.ST.REC.Z) , « = {IF.OF.IOF,1TF.OTF) 

0 D = {B.CH.AZ,1} 


- BUCHSTABE 


•• BUCHSTABE •• 


• • ZIFFER ••• 

j-Oj 


ADA 67: ZIFFER ADA 68: BUCHSTABE 



wird das Schreiben von Namen geregelt. Demnach beginnt ein 
Name stets mit einem Buchstaben, dem in beliebiger Reihen- 
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folge Buchstaben oder Ziffern folgen können. Dabei darf 
zwischen zwei Buchstaben oder Ziffern eines Namens ein Unter¬ 
strich stehen. 


grammatikalisch 


zulässig 

unzulässig 

bl 

105 

epsilon 

Vorsicht! 

zinsl 

lzins 

zins_fuss 

zinsfuss 


2.2,2 T-SYNTAXDIAGRAMME 

Wie wir gesehen haben, wird eine exakte und übersichtliche 
Beschreibung einer Programmiersprache durch die Notation der 
Syntax in Syntaxdiagrammen erreicht. Um eine möglichst kom¬ 
pakte Schreibweise zu erzielen, werden diese jedoch nicht 
nur in der bisher beschriebenen einfachsten Form, sondern 
auch in kollektiver,selektiver und 
mehrschi chti ger Schreibweise als sogenannte 
T-Diagramme verwendet. 

T-Diagramme erlauben es, durch die Verwendung von T-Syntax¬ 
variablen, einerseits ohne Rücksicht auf die Typkennzeich¬ 
nung (für T), sich eine grammatikalische Übersicht über 
Sprachelemente zu verschaffen, andererseits aber auch eine 
grammatikalisch korrekte Produktion von Sprachelementen 
typgebunden (mit Berücksichtigung der jeweils für T gegebe¬ 
nen Vorschrift) durchzuführen. 

Im letzteren Falle darf also grundsätzlich eine T-Syntaxva- 
riable erst dann bei der Produktion eliminiert werden, wenn 
für T ein entsprechend zugelassener Typ festgelegt und ein¬ 
gesetzt wurde bzw. als zulässig befunden wurde. 




2.2.2 T-Syntaxdiagramme 
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Es treten daher zwei mögliche Fälle auf: Tritt eine T-Syn- 
taxvariable als Diagrammbezeichner (Überschrift) auf, so 
handelt es sich um ein mehrschichtiges Diagramm (a). Tritt 
jedoch eine T-Syntaxvariable innerhalb eines Diagrammes auf, 
so handelt es sich entweder um einen kollektiven (b) oder 
selektiven (c) Diagrammzweig. In diesem Falle (b) oder (c) 
darf also bei einer Produktion erst dann eliminiert werden, 
nachdem für T ein Typ eingesetzt wurde bzw. T den vorge¬ 
schriebenen Typ darstellt. 

(a) Mehrschichtige Diagramme: 

Diagramme, die sich nur nach dem Typ unterscheiden (also 
nach statischer Semantik), werden zu einem mehrschichti¬ 
gen Diagramm mit einer T-Syntaxvariable zusammengefaßt 
(Metasprache für Syntaxvariable, zweischichtige Gramma¬ 
tik). In dem Diagramm 


ADA 28: T AUSDRUCK (T AUSDR, r A) Teeu* 

0 ■ {B,CH,AZ,I,G,F,A,ST,REC,Z} , * * {1F,0F,IOF,ITF,0TF) 

- T REL - 


werden durch die Vorschrift T 6 0 U $ 15 elementar 
notierte Diagramme festgelegt. Zum Beispiel erhält man 
für T = G das Diagramm: 


ADA 28: G AUSDRUCK 


G REL 
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(b) Kollektive Diagramme: 

Die Verwendung von T-Syntaxvariablen tragen zur wesent¬ 
lichen Abkürzung der Diagrammschreibweise bei. In dem 
Diagramm 


ADA 25: ITERATIONSKLAUSEL (ITER KLAUSEL) 

0 D => {B, CH, AZ, I} 


-5— for - T VAR NAME -in — |— reverse —| 


INDEX BER 


- whiie — B AUSDR - 


1 


werden durch die Vorschrift T 6 Op (0p heißt "Kollek¬ 
tor") 4 gleichstrukturierte Diagrammzeilen in einer ein¬ 
zigen Zeile zusammengefaßt. In ausführlicher Schreibwei¬ 
se erhält das Diagramm die Form: 

ADA 25: ITERATIONSKLAUSEL (ITER KLAUSEL) 


-for - B VAR NAME - in —T— reverse 

— for - CH VAR NAME — in 

— for — AZ VAR NAME — in 

— for — I VAR NAME — in 


I L 

— |— reverse —| 
— j— reverse —j 
— |— reverse —| 


INDEX BER 


CH INDEX BER - 


AZ INDEX BER - 


I TNT1FY RFR _ 


— whne — ß AUSDR 


In einem Diagramm können an verschiedenen Stellen Kollek¬ 
toren auftreten: 

ADA 28: t AUSDRUCK ( T AUSDR, r A) reou* 

0 => {B,CH,AZ , I ,G,F,A,ST,REC,Z) , 4> = (IF ,0F, IOF, ITF ,0TF} 


■ T REL - 


- T REL 


- and - \ REL - 


- T, REL 


\ REL 







































2.2.2 T-Syntaxdiagramme 
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Wir finden hier die beiden Kollektorangaben Tj 6 0 U $ 
und p0U$ vor. Beim Durchlauf an diesen Kollektoran- 
gaben ist jeweils ein Typ T ? bzw. aus dem zugehörigen 
Kollektor o u $ zu wählen. Steht also eine Kollektoran¬ 
gabe an einem Diagrammzweig innerhalb einer Rekursion, 
so ist für diesen Diagrammzweig bei jedem Durchlauf ein 
Typ aus dem Kollektor zu wählen (natürlich unabhängig 
von vorangegangenen und nachfolgenden Festlegungen). 
Steht dagegen die Kollektorangabe vor der Rekursion, so 
ist natürlich die erstmalige Wahl für alle Durchläufe 
der Rekursion bindend. 


(c) Selektive T-Diagramme: 

Diese Schreibweise erlaubt das Zusammenfassen von seman¬ 
tisch gleichartigen, jedoch syntaktisch unterschiedli¬ 
chen Sprache!ementen zu einem T-Diagramm. Wir verwenden 
in den Diagrammzeilen sogenannte Sei ektoren 
der Form 

-( T6{B,CH,AZ} )- 

die den Durchlauf an dieser Stelle nur dann frei geben, 
wenn eine Produktion für einen aufgelisteten Typ durch¬ 
geführt wird. 


In dem Diagramm 


ADA 28: T AUSDRUCK (t AUSDR, t A) Teeu* 

0 = {n,CM,AZ,I ,G,F,A,ST,REC,Z} . « = {I F,0F. I OF .I TF , OTF ) 



Pex Exgebnl&typ T iit duxch den 
zuletzt ang wendeten Openatox 
btetumt. 


Pxioxität I 
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besitzen die beiden letzten Zeilen Selektoren mit Tj =B. 
Diese Zeilen können also nur durchlaufen werden, wenn 
zuvor für Tj REL der Typ B aus dem Kollektor 0 U $ ge- 
wählt wurde. 


2.3 SEMANTIK 

Die Semantik gibt zu jedem Programm der Sprache eine Bedeu¬ 
tung an. Im Sinne der Datenverarbeitung sagt die Bedeutung 
darüber etwas aus, wie die eingegebenen Daten verarbeitet 
bzw. Daten erzeugt werden. Der Einfachheit halber beschreibt 
man die Bedeutung von Sprachelementen entsprechend ihrem 
grammatikalischen Aufbau. Die Beschreibung eines Programmes 
setzt sich im wesentlichen aus den Bedeutungen der verwen¬ 
deten Sprachelemente zusammen. 

Die Semantik läßt sich nicht in Diagrammform beschreiben, 
sondern kann hier sinnvoll nur umgangssprachlich angegeben 
werden. Bei der Beschreibung ist zu beachten, daß die Bedeu¬ 
tung der Sprachelemente sehr streng formuliert ist, um Mehr¬ 
deutigkeiten zu vermeiden. Es kommt daher oft auf jedes Wort 
und auf die Wortstellung an. 

Der öfter auftretende Begriff "maschinenabhängig" besagt, 
daß der damit beschriebene Vorgang bzw. das damit beschrie¬ 
bene Sprachelement abhängig ist von der Implementierung der 
Sprache auf einer Rechenanlage. Die für eine Rechenanlage 
zutreffende Festlegung ist entsprechenden Handbüchern der 
Rechenanlage zu entnehmen. 


2A PRAGMATIK 


Die Pragmatik ist Teil der Semantik und umfaßt letztendlich 


2.4 Pragmatik 
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den Teil der Sprache, der als allgemein bekannt vorausge¬ 
setzt und daher nicht weiter erläutert wird. Beispielsweise 
wird bei oben genanntem I AUSDRUCK die Bedeutung der Zeichen 
+ , -, (, ) usw. nicht näher erläutert, sondern als jedem 
geläufig vorausgesetzt. 
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3, HINWEISE ZUM LESEN DES BUCHES 


Zur Schreibweise der einzelnen Abschnitte ist folgendes zu 

bemerken: 

- Innerhalb eines Abschnittes bezeichnen in Groß¬ 
buchstaben geschriebene Worte Syntaxvariable, 
die Bezug nehmen auf Teile des gerade behandelten Diagram 
mes. Wird dagegen das zugehörige Diagramm selbst angespro 
chen, so ist stets die entsprechende Diagrammnummer nach¬ 
folgend angegeben. 

- Kursiv geschriebene Wortfolgen bezeich¬ 
nen die in der gleichen Weise gekennzeichneten Teile in 
den Syntaxdiagrammen. (Dies trifft jedoch nicht für die 
erläuternden Kommentare in den Beispielen zur Semantik 
zu). 

Zur Hervorhebung werden solche Wortfolgen auch zusätzlich 
gesperrt geschrieben. 

- Gesperrt und nicht kursiv geschrie¬ 
bene Wortfolgen geben die Stelle der Definition dieses 
Begriffes an. 

- Zitate von Abschnitten ohne Kapitelangabe beziehen sich 
auf das Kapitel, in dem das Zitat steht. 

- Literaturverweise werden in der üblichen Form durch eine 
Nummer in eckigen Klammern gegeben (z.B. [5]). Der ent¬ 
sprechende Titel ist im Literaturverzeichnis E. zu finden 

- Viele Beispiele in den laufenden Abschnitten sind voll¬ 
ständigen und umfassenden Programmen entnommen, welche 
gesammelt am Ende eines Kapitels aufgeführt sind. 


1. Programmaufbau 
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B. DAS ADA PROGRAMM 


1. PROGRAMMAUFBAU 


Ein P/iogKamm besteht aus einer oder mehreren parallelen oder 
geschachtelten Programmeinheiten. Es gibt 3 verschiedene Ar¬ 
ten solcher Einheiten, nämlich Unterprogramme, Pakete und 
Prozesse. Im einfachsten Fall besteht ein Programm nur aus 
einem Unterprogramm, einer sogenannten Prozedur. 

Syntaktisch läßt sich ein Programm in übznAztzunQ&QsLnkiiitm 
unterteilen. Ein UNTERPROGRAMM, eine UNTERPROGRAMMSPEZIFIKA¬ 
TION, ein PAKETRUMPF oder eine PAKETSPEZIFIKATION sind 
übersetzungsei nhei ten. 

Ferner können auch Unterprogramm- und Paketschemata verein¬ 
bart werden, aus denen durch Angabe von Argumenten aktuelle 
Unterprogramme oder Pakete erzeugt werden. Auch diese Sche¬ 
maspezifikationen oder Erzeugungen sind Überset¬ 
zungseinheiten. 

Der Rumpf eines Unterprogrammes, Paketes oder Prozesses läßt 
sich als Un£e.sie.ZnheAX formulieren und bildet dann auch eine 
Übersetzungseinheit. 
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Syntax: 

ADA 1: PROGRAMM 



Jede Übersetzungseinheit besitzt einen Namen. Die Namen aller 
Übersetzungseinheiten eines Programms sind verschieden zu 
wählen mit der Ausnahme, daß ein Unterprogramm den gleichen 
Namen wie die Unterprogrammspezifikation und ein Paketrumpf 
den gleichen Namen wie die Paketspezifikation tragen muß. 

Im allgemeinen wird ein Programm nicht als ganzes übersetzt 
werden, sondern die einzelnen Übersetzungseinheiten jeweils 
für sich. Dabei kann mittels einer KONTEXTANGABE auf andere 
Übersetzungseinheiten, die in einer Bibliothek vorhanden 
sind, Bezug genommen werden. Die beiden Übersetzungseinheiten 
UNTERPROGRAMM und UNTERPROGRAMMSPEZIFIKATION sowie PAKET¬ 
RUMPF und PAKETSPEZIFIKATION werden durch ihren gemeinsamen 
Namen gleichzeitig sichtbar. Untereinheiten sind keine Bib¬ 
liothekseinheiten (siehe 10). 

Es darf kein Unterschied bestehen, ob die Übersetzungseinhei¬ 
ten eines Programms getrennt oder gemeinsam übersetzt werden. 
Wird ein Programm gemeinsam übersetzt, so gilt die Reihenfol¬ 
ge der auftretenden Übersetzungseinheiten. Alle in Kontext- 





























1. Programmaufbau 
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angaben vorkommenden Übersetzungseinheiten müssen zu diesem 
Zeitpunkt bereits verarbeitet sein. Man beachte, daß ein 
Rumpf einer Programmeinheit nach der entsprechenden Spezifi¬ 
kation übersetzt wird, und Untereinheiten nach der entspre¬ 
chenden Einheit. 

Bei getrennter Übersetzung werden die bereits übersetzten 
Übersetzungseinheiten in der Reihenfolge wieder herangezogen, 
in der sie in Kontextangaben der zu übersetzenden oder be¬ 
reits herangezogenen Übersetzungseinheiten auftreten. 

Es muß sich also eine Ordnung hersteilen lassen, in der alle 
Übersetzungseinheiten eines Programms gemeinsam übersetzt 
werden könnten (vgl. 10). 

Die Ausführung eines Programmes beginnt mit dem 
systemabhängigen Anstoß der Ausführung eines Unterprogrammes. 
Dieses Unterprogramm übernimmt also für diese Ausführung die 
Rolle eines Hauptprogrammes im üblichen Sinne. 

Die Ausführung einer Programmeinheit beginnt mit der Verar¬ 
beitung der Vereinbarungen und Definitionen, sodann wird der 
Anweisungsteil ausgeführt, beginnend mit der ersten Anwei¬ 
sung. Nach Ausführung einer Anweisung wird deren Nachfolge¬ 
anweisung ausgeführt. Dabei ist die zu einer Anweisung a ge¬ 
hörige Nachfolgeanweisung $ entweder die 
durch die Anweisung a ausdrücklich als nachfolgend festgeleg¬ 
te Anweisung $ oder andernfalls die physikalisch nachfolgen¬ 
de Anweisung. Die Ausführung einer Programmeinheit wird 
durch Ausführung einer return -Anweisung oder durch Erreichen 
des Endes des Anweisungstei1s beendet. 

Regeln zum Schreiben von Programmen: 

(1) Ein Programm wird zeilenweise geschrieben. Am Ende einer 
Zeile kann, durch -- eingeleitet, ein Kommentar stehen. 


3 Kaucher IV - ADA A 
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KOMMENTAR 

-GD — TEXT-Zeilenende 


TEXT ist dabei eine beliebige Zeichenfolge. 

Der verwendete Zeichensatz sollte alle Großbuchstaben und 
Ziffern, das Leerzeichen und folgende Sonderzeichen (bzw. 
die angegebenen Ersatzzeichen) enthalten: 

+ -*/&(). : ; = <> 

1 _ | bzw. ! " bzw. % # bzw. : 

(2) Innerhalb von Wortsymbolen, Namen und Zahlen dürfen keine 
Trennzeichen stehen. Dabei versteht man unter einem 
Trennzeichen ein Leerzeichen oder ein Zeilenendezeichen. 

(3) Zwischen zwei unmittelbar aufeinanderfolgenden Namen, 
Zahlen oder Wortsymbolen muß mindestens ein Trennzeichen 
stehen. 

(4) Bis auf die Regeln (2) und (3) können Trennzeichen belie¬ 
big zur übersichtlichen Gestaltung des Programmes verwen¬ 
det werden. Trennzeichen haben außer ihrer Trennfunktion 
keine Bedeutung für die Ausführung des Programmes. 

(5) Bei der Identifizierung von Namen und Wortsymbolen wird 
kein Unterschied zwischen entsprechenden Groß- und Klein¬ 
buchstaben gemacht. 

(6) Für einen Namen sind alle verwendeten Zeichen signifi¬ 
kant. 

(7) Wortsymbole dürfen nicht als Namen verwendet werden. Sie 
werden wie Namen geschrieben. In diesem Buch sind sie zur 
Unterscheidung unterstrichen. 

(8) Reservierte Namen, wie z.B. integer dürfen in einer Pro¬ 
grammeinheit neu definiert werden. 



1. Programnaufbau 
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Ein Verzeichnis der Wortsymbole und reservierten Namen findet 
sich in D.2 und D.3. 

Ein Name hat die folgende Form. 


I 


Syntax: 


ADA 65: NAHE 


■ BUCHSTABE - 


•• BUCHSTABE •• 


.... Z i FFER ... 

l-O-j 


Ein Name dient zur Identifizierung der durch ihn bezeichneten 
Größe. Man beachte die Regeln (5) bis (8) zum Schreiben von 
Programmen. 

Hinweis: 

In den Syntaxdiagrammen tritt NAME nie allein auf, sondern 
stets mit einem Hinweis auf den Verwendungszweck, z.B. 

I TYPNAME oder UPG NAME (Unterprogrammname). 

Sollen Namen aus anderen Programmeinheiten oder Blöcken ver¬ 
wendet werden, so werden sie mit dem Namen dieser Einheit als 
Präfix versehen. Solche Einheitsnamen heißen hier ZUNAMEN. 

Syntax: 


ADA 58: ZUNAME (ZUN) 


PGE NAME - 

- BLOCK NAME 

- SCHL NAME 


3* 
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Semantik: 

Ein Zuname ist stets einem Namen vorangestellt. Er bezeichnet 
die Einheit, in der der Name sichtbar ist. Genaueres folgt in 
10.3 . 


Durch eine KONTEXTANGABE können einer Übersetzungseinheit 
Größen aus anderen Bibliothekseinheiten zugänglich gemacht 
und deren Bezeichnung vereinfacht werden (siehe 10). 


Nur sehr einfache Programme kommen ohne Kontextangaben aus. 
Bereits für Ein- und Ausgabe muß auf entsprechende Standard¬ 
pakete durch eine Kontextangabe hingewiesen werden (siehe 4.3 
oder 11). 


Beispiel 1: Newtonverfahren 

1 x ^-1 

Bestimmung einer Nullstelle der Funktion f(x) = sin^-x + -y 


4.~ 2, 


xN-1 


rm 


t der Ableitung f'(x) = ^-cosix + x — 2 X *£ x nach dem New- 

2 (xW 


tonverfahren: x Q beliebiger Startwert 


f(\) 

X k+1 = x k ” TJT) 


, k = 0,1,... . 


Es soll solange iteriert werden, bis —-| < e ist. 


Dabei sind x Q und e einzulesen, x^ ist für jeden Schritt 
auszudrucken. 


Version 1: 

-- Eine Prozedur, die 2 Funktionen enthält 
-- außerdem 2 Pakete, die als Bibliothekseinheiten 
-- vorhanden seien 

with Standard_EA, Standard_Funktionen; 
use Standard_EA, Standard_Funktionen; 

-- Standard_EA ist ein Paket mit Ein- und Ausgabeproze- 
-- duren für die Standardtypen (s. 4.3) 










1.1 Unterprogramme 
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-- Standard_Funktionen ist ein Paket für die Berechnung 
-- arithmetischer Standardfunktionen (s. 1.2) 
procedure Newton i_s 
xk,xkl,eps : float; 
function f (x : float) return float is 
begin 

return sin(ß.5*x)+(x?x*x- 1.0)/(x * x + 1.0); 
end f; 

function fs (x : float) return float is 
q,y : float; 
begin 

q:= x * x; y:= q + 1.0; 

return 0.5 * cos (0.5 * x) - (q*q + 3.0*q + 2.0*x)/ 

(y*y); 

end fs; 

begin -- Newton 

get(xkl); 
get(eps); 

Iteration: loop 

xk:= xkl; 

xk1:= xk - f(xk)/fs(xk); 
put(xkl); 

exit when abs((xkl- xk)/xk) < eps; 
end loop Iteration; 
end Newton; 


1.1 UNTERPROGRAMME 

Als Unterprogramme stehen wie üblich Prozeduren und Funktio¬ 
nen zur Verfügung. Als spezielle Funktionen lassen sich zu¬ 
sätzlich Operatoren vereinbaren. 
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Syntax: 


ADA 6: UNTERPROGRAMM (UPG) 


- UPG SPEZIF — li -r VEREINBTL 


IsjVEREINBH—| i- 

I-L begin -L 


ANW j exception j AUSN BEHTL- 1 

I- 1 -L end —f— PZD NAME — 


T FKT NAME - 
r OPERATOR - 


Utt te'ifMog'iammujnp^ 


UPG SPEZIF 
Unte.\piog\ammeunc. 


ADA 7: UNTERPROGRAMM SPEZIFIKATION (UPG SPEZIF) 

0 = (B.CH.AZ,I,G,F,A,ST,REC,Z) , « * {IF,OF,IOF,ITF.OTF) 

— procedure — PZD NAME - r- FORMALE ARGUMENTLISTE • 


1 


• function _ T FKT NAME -1 

L T OPERATOR - FORMALE ARGUMENTLISTE 


1 


Un tcAFWogM/nmnaflie 


return — T JYP — 

Efigebni&typ 


Funktion 

OpeAaXon 


Semantik: 


Bei einer Vielzahl von Unterprogrammen läßt sich die Lesbar¬ 
keit des Programmes erhöhen durch eine zusätzliche, eigen¬ 
ständige UNTERPROGRAMMSPEZIFIKATION. Sie muß mit der im Un¬ 
terprogramm stehenden Spezifikation identisch sein bis auf 
mögliche Unterschiede in der Schreibweise der Namen der for¬ 
malen Argumente. Falls sich zwei Unterprogramme gegenseitig 
aufrufen, ist eine eigenständige Unterprogrammspezifikation 
unumgänglich. 

Die Verarbeitung einer Unterprogrammspezifikation wird, auch 
wenn diese wiederholt wird, nur einmal vorgenommen. Sie be¬ 
ginnt mit der Einführung des Namens, dann werden die formalen 
Argumente in der Reihenfolge ihres Auftretens verarbeitet, 
bei Funktionen folgt die Verarbeitung des Resultattyps. 
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Die Ausführung eines Unterprogrammes wird durch den Aufruf 
bewirkt. Die Ausführung beginnt nach der Argumentübergabe, 
wie bereits erwähnt, mit der Verarbeitung des Vereinbarungs¬ 
teils. Anschließend werden die Anweisungen ausgeführt. 


1.2 PAKETE 

Ein Paket besteht in der Regel aus der Paketspezifikation und 
dem Paketrumpf. 

Syntax: 


ADA 9: PAKETRUMPF 


— package - bodjr - PAK NAME -1* -r VEREINBTL -1 




j; 


I | AUSN BEHTL —| 


i | PAK NAME -| 


Anw iiungi teil 


ADA 10: PAKETSPEZIFIKATION (PAK SPEZIF) 
i*-VEREINB- : 


— package - PAK NAME - i£ 


•VEREINB 


i-DARST ANG* 


end -r- PAK NAME n 


T 


siditbcLXen. Teil 


ge&chiUzten Te.il de* Pakete* 
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B.l Programmaufbau 


Semantik: 

Ein Paket dient zur Sammlung von Konstantem, Datentypen und 
Unterprogrammen. Falls keine Unterprogramme auftreten, kann 
ein Paket nur aus der Paketspezifikation bestehen. Im sicht¬ 
baren Teil stehen die Vereinbarungen und Spezifikationen, di 
an anderen Stellen des Programmes verwendet werden dürfen. 

Im geschützten Teil steht die ausführliche Beschreibung der 
geschützten Typen. Im Rumpf sind die Unterprogramme verein¬ 
bart, deren Spezifikationen im sichtbaren Teil aufgeführt 
sind. Außerdem können hier wie auch im geschützten Teil wei¬ 
tere Größen (Typen, Variable, Unterprogramme,...) vereinbart 
werden, auf die an anderen Stellen des Programmes nicht zu¬ 
gegriffen werden kann. 

Die Verarbeitung eines Paketes beginnt mit der Verarbeitung 
der Paketspezifikation, es folgt der Vereinbarungsteil des 
Rumpfes, anschließend werden die Anweisungen des Rumpfes aus 
geführt. 

Diese dienen, falls überhaupt vorhanden, vornehmlich der Ini 
tialisierung des Paketes. 

Beispiel: Paket Standardfunktionen 

package Standard_Funktionen *is 

function sqrt (x : float) return float; 
function exp (x : float) return float; 
function ln (x : float) return float; 
function arctan (x : float) return float; 
function sin (x : float) return float; 
function cos (x : float) return float; 
end ; 

package body Standard_Funktionen is 
type long _^s digits 20; 

function sincos (x : float; b : boolean) return float is^ 
function argument reduction (x : float) return long; 
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function approx (y : long) return long is 

begin — Berechnung einer Approximation für sin 
*’* — bzw. cos 


end ; 

function sin (x : float) return float is 
begin 

return sincos (x,true); 
end ; 

function cos (x : float) return float is 
begin 

return sincos (x,false); 
end; 


end; 


1.3 PROZESSE 

Während alle anderen Programmeinheiten sequentiell ablaufen, 
bieten Prozesse die Möglichkeiten zur Parallelarbeit. Alle in 
einer Übersetzungseinheit vereinbarten Prozesse werden zu Be¬ 
ginn des Anweisungsteils dieser Übersetzungseinheit gleich¬ 
zeitig aktiviert und führen ihre Anweisungsfolgen parallel, 
d.h. unabhängig voneinander, aus. Zur Synchronisierung von 
Prozessen dienen spezielle Anweisungen (siehe 9). 

Beispiel 1: Version 2 

Die Berechnung von f(x) und f'(x) geschieht durch zwei paral¬ 
lele Prozesse. 

wi th Standard_EA, Standard_Funktionen; 
use Standard_EA, Standard_Funktionen; 
procedure Newton j_s 

fsxk,fxk,xk,xkl,eps : float; 
task f is 
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B.l Programmaufbau 


entry arg (x : iji float); 
entry wert (x : out float); 
end ; 

task body f is_ 
z : float; 
begin loop 

accept arg (x : i_n float) do 
z:= x; 
end ; 

z:= sin(0.5*z) + (z*z*z-1.0)/(z*z+1.0) 
select accept wert (x : out float) do 
x:= z; 
end ; 

or terminate ; 
end select ; 
end loop ; 

end f; 
task fs is 

entry arg (x : i_n float); 
entry wert (x : out float); 
end ; 

task body fs 
y ,q ,z : float; 
begin loop 

accept arg (x : j_n float) do 
z:= x; 
end ; 

q:= z * z; 
y: = q + 1.0; 

z:= 0.5* cos(0.5* z) - (q*q + 3.0*q + 

2.0* z)/(y*y); 

select accept wert (x : out float) do 
x:= z; 
end; 
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or terminate ; 
end select; 
end loop ; 
end fs; 

begin -- Newton 
get(xkl); 
get(eps); 

Iteration: loop 

xk:= xkl 
f.arg(xk); 

fs.arg(xk); — Start der parallelen 

-- Berechnung von f und fs 

f.wert(fxk); 
fs.wert(fsxk); 
xk1:= xk - fxk/fsxk; 
put (xkl); 

exit when (abs(xkl - xk)/xk) < eps; 
end loop Iteration; 
end Newton; 

— Durch andere Aufteilung der Schleife 

-- (Aufruf von f. und fs.arg unmittelbar nach Aufruf von 
-- wert und einmal vor der Schleife) erhöht sich die Ge- 
-- schwindigkeit, da während der Funktionsberechnung die 

— Iterationsberechnung durchgeführt wird. 


1.4 UNTEREINHEITEN 

Der Rumpf eines Unterprogrammes, Paketes oder Prozesses kann 
als Untereinheit getrennt übersetzt werden. Dadurch erhöht 
sich die Übersichtlichkeit, da die Vereinbarungen dichter zu¬ 
sammenstehen, außerdem lassen sich so gegenseitige Aufrufe 
formulieren. 
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B.l Programmaufbau 


Syntax: 


AUS ADA 1: PROGRAMM 


■ separate -0~ ZUN — PGE NAME — Q 


Bibliothckieinhzit 


- UNTERPROGRAMM 

- PAKET RUMPF - 

- PROZESS RUMPF 


Untereinheiten lassen sich schachteln. Die zu einer Unterein¬ 
heit unmittelbar übergeordnete Einheit heißt Mutter- 
e i n h e i t . 

Die Namen aller (auch der geschachtelten) Untereinheiten ei¬ 
ner Bibliothekseinheit müssen verschieden sein, während ver¬ 
schiedene Bibliothekseinheiten Untereinheiten gleichen Na¬ 
mens besitzen dürfen. 

Im Vereinbarungsteil der Muttereinheit muß als Hinweis auf 
die Untereinheit der Rumpf in rudimentärer Form (als Rumpf¬ 
stumpf) vereinbart werden. 

Syntax: 


AUS ADA 17: VEREINBARUNGSTEIL (VEREINBTL) 


Kumpi-Stumpi 
alt Hinvtib olu& 
eine zag zhonÄge. 
g eAwnnt üben- 
ietzte Un-tc*- 
eAJthe^t 


UNTERPROGRAMM SPEZIFIKATION 


J — package - body — PAK NAME - 

1— task - body — PZS NAME - 


—©- 


Der Untereinheit sind alle Bibliothekseinheiten, die der Mut¬ 
tereinheit sichtbar sind, ebenfalls sichtbar, so als ob sie 
anstelle des Rumpfstumpfes stünde. Zusätzlich können mittels 
Kontextangaben weitere sichtbar gemacht werden. 
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Beispiel 1: Version 3 
Newtonverfahren mit Untereinheiten. 

with Standard_EA, Standard_Funktionen; 
use Standard_EA, Standard_Funktionen; 
procedure Newton j_s 
xk,xkl,eps : float; 

function f (x : float) return float is separate ; 
function fs (x : float) return float i_s separate ; 

end Newton; 

separate (Newton) function f (x : float) return float 
is begin 

return sin(0.5*x)+(x**3- 1.0)/(x*x+1.0); 
end f; 

separate (Newton) function fs (x : float) return float 
is q,y : float; 
begin 

q:= x * x; 
y:= q + 1.0; 

return 0.5*cos(0.5*x) - (q*q+3.0*q+2.0*x)/(y*y) 
end fs; 
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B.2 Vereinbarungen 


2. VEREINBARUNGEN 

Die Namen für Typen, Konstanten und Variablen, Unterprogram¬ 
me, Pakete, Prozesse und Ausnahmen müssen vor ihrer Verwen¬ 
dung als solche kenntlich gemacht werden, d.h. sie müssen in 
einer entsprechenden Vereinbarung stehen. Standardnamen dür¬ 
fen nicht vereinbart werden, falls sie in ihrer ursprüngli¬ 
chen Bedeutung verwendet werden sollen. Die Namen von Marken, 
Blöcken und Schleifen werden implizit durch ihr Auftreten 
vereinbart. 

Eine Vereinbarung für Parameter, Eingänge, Diskriminanten 
oder Komponenten geschieht innerhalb einer der oben angegebe¬ 
nen Vereinbarungen. 

Wir unterscheiden zwischen einer Folge von VEREINBARUNGEN 
und einem VEREINBARUNGSTEIL. 

Stets muß in ADA eine Größe vereinbart werden, bevor sie ver¬ 
wendet wird. Abgesehen von dieser Grundregel ist die Reihen¬ 
folge der Vereinbarungen beliebig. Im Vereinbarungsteil kom¬ 
men möglicherweise zu den Vereinbarungen noch die Darstel¬ 
lungsangaben und die Rümpfe der spezifizierten Programmein¬ 
heiten oder aber Hinweise auf separat übersetzte Programm¬ 
einheiten in Form von Rumpfstümpfen. Dadurch wird nun eine 
etwas strengere Reihenfolge festgelegt, z.B. darf nach einer 
Darstellungsangabe keine Typvereinbarung mehr stehen. Die 
genaue Syntax zeigt das Diagramm 
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ADA 17: VEREINBARUNGSTEIL (VEREINBTL) 


VEREINB • 


DARST ANG 


1 


Rumpf-Stumpf 
a(i Minute.ii auf 
eine zugehörige 
getrennt über- 
ietzte Unter¬ 
einheit 


UNTERPROGRAMM - 

PAKET RUMPF - 

PAKET SPEZIFIKATION - 

PAKET ERZEUGUNG - 

■ PROZESS RUMPF - 


• PROZESS SPEZIFIKATION - 


UNTERPROGRAMM SPEZIFIKATION 

— package - body — PAK NAME — 

- Usk-bod* * — PZS NAME - 


- is - separate — 


n. 


Semantik: 

Zusammengehörige Teile von Programmeinheiten, also PAKETSPE¬ 
ZIFIKATION und PAKETRUMPF, PROZESSPEZIFIKATION und PROZESS¬ 
RUMPF, getrennt vorhandene UNTERPROGRAMMSPEZIFIKATION und 

UNTERPROGRAMM, müssen in einem Vereinbarungsteil auftreten. 

Hinweise: 

(1) Man beachte, daß z.B. eine Paketspezifikation einer¬ 
seits eine VEREINBARUNG ist, andererseits aber auch 
nach einer DARSTELLUNGSANGABE auftreten kann. 

(2) Als Faustregel Uber die Reihenfolge im Vereinbarungs¬ 
teil kann man sich merken: Zuerst Vereinbarungen, dann 
Darstellungsangaben, dann Rümpfe. 

(3) Die einzige Stelle, an der eine Folge von Vereinbarun¬ 
gen, gefolgt von Darstellungsangaben, anstelle eines 
Vereinbarungsteils steht, ist innerhalb des geschützten 
Teils einer Paketvereinbarung. Es scheint auch wenig 
sinnvoll, Rümpfe von Programmeinheiten aus dem ge¬ 
schützten Teil auszulagern. 
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B.2 Vereinbarungen 


Durch Angabe einer use- Klausel wird der Zuname für die Größen 
des entsprechenden Paketes in der aktuellen Programmeinheit 
eingeführt und braucht dann nicht mehr angegeben zu werden. 

Syntax: 


AUS ADA 18: VEREINBARUNG 


- use 



. O .s 

ZUN — PAK NAME —^- 


use-Klaiuel 


Betreffs der Verwendung gleicher Namen für verschiedene Grö¬ 
ßen vergleiche 10. Im einfachsten Fall werden die Namen al¬ 
ler verwendeten Größen verschieden sein. 


2.1 DIE VEREINBARUNG VON TYPEN 

Es gibt Typen für Datenobjekte und für Prozesse. Die Verein¬ 
barung von Prozeßtypen wird in 2.6 behandelt. Beinhaltet das 
Programm ei ne Eingabe oder Ausgabe, so werden noch Typen für 
Dateien (Files) gebraucht. Diese werden in speziellen Pake¬ 
ten bereitgehalten. Die Handhabung von Files wird in 11 be¬ 
schrieben. Ein (Daten-)Typ besteht aus einem Wertebereich und 
einer Menge vorgegebener Operationen. 

Die Typen lassen sich in 3 Gruppen unterteilen. Die skalaren 
Typen, die strukturierten Typen und die Zeigertypen. Obwohl 
sich die Files als spezielle strukturierte Typen auffassen 
ließen, werden sie wegen ihrer Sonderstellung als eine eigene 
Gruppe betrachtet. Die weitere Aufteilung sowie die im Text 
und den Syntaxdiagrammen verwendeten Abkürzungen zeigt das 
folgende Bild. 






2.1 Typen 


Übersicht über die Typen 


skalar " 


dis¬ 

kret 


nume¬ 

risch 


struk¬ 

tu¬ 

riert 

Zeiger j 


File < 


Prozeß | 


Auf- 
41 zäh- 
1 ung 


reel 1 


Array 


File 

Text¬ 

file 


boolean 
- character 
Aufzählung 
integer 
I Gleitpunkt 
1 Festpunkt 
f Array 
\ String 
Record 
Zeiger 
i n_f i 1 e 
' out_file 
inout_file 
I Eingabetextfile 
[ Ausgabetextfile 
Prozeß 


Die Datentypen werden zur Menge 
0 = (B,CH,AZ,I,G,F,A,ST,REC,Z} 
und die Filetypen zur Menge 
$ = {IF,0F,I0F,ITF,0TF} 
zusammengefaßt. 


B 

CH 

AZ 

I 



REC 

Z 


IF 

OF 

IOF 

ITF 

OTF 

PZS 


Ferner fassen wir die diskreten Typen in der Menge 
Gß = {B,CH,AZ,I} zusammen. 


Syntax: 

aus ADA 18 : VEREINBARUNG 


T ypveAeXnbaA.ung 

reeu$ 


mi — T TYP NAME —|-{t=rec)- FOR DISKR LISTE 




- ü — r typ DEF — 

iiuwoltit. TtjpvcAtinb. I 


4 Kaucher IV - ADA 
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B.2 Vereinbarungen 


Semantik: 

Zuerst wird der Typname eingeführt, dann folgt die Verarbei¬ 
tung der formalen Diskriminantenliste, falls vorhanden, und 
anschließend die Verarbeitung der Typdefinition. Verschiede¬ 
ne Typvereinbarungen erzeugen stets verschiedene Typen, wel¬ 
che stets imkompatibel sind. Siehe 2.1.4. 

Nur für Zeigertypen oder Typen, die Zeigertypen enthalten, 
kann die unvollständige Typvereinbarung benutzt werden, um 
rekursive oder gegenseitig voneinander abhängige Typen zu 
vereinbaren. 


2 . 1,1 DIE SKALAREN TYPEN 

Die Wertebereiche der skalaren Typen sind linear geordnet. 
Entsprechend dieser Ordnung lassen sich durch Einschränkung 
des Wertebereichs Unterbereiche angeben. 


2 . 1 . 1.1 DIE DISKRETEN TYPEN 


Die diskreten Typen treten auf als Indexbereiche von Feldern, 
als Laufbereiche in Wiederholungsanweisungen, als Diskrimi¬ 
nanten und zur Auswahl in Auswahlanweisungen. 

Gß = {B,CH,AZ,I} sei die Menge der diskreten Typen. 

Syntax: 

Aus 


ADA 22: T TYP 


-Ar 6 (B.ch.az. I }•) - ZUN — t TYP NAME - 

■<t-b)- 


—TbooTearw 


■(r»i)— 


—(charac tor)- 


Be le icJiA eXni ch tön tun g 


t EINF AUS -Q- r E1NF AUS 

untere Schlanke obeie Schlanke 


1 


















2.1.1.1.1 Aufzählungstyp 
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Semantik: 

Jedem Wert eines diskreten Typs ist eine ganzzahlige Posi¬ 
tionsnummer zugeordnet, die die Ordnung bestimmt. Sei X der 
Wert der unteren Schranke, p der Wert der oberen Schranke. 
Dann erfüllt ein Wert y die Bereichseinschränkung, falls 
\ < Y < p, Falls x > p, so ist der diskrete Unterbereich 
leer. Eine Bereichseinschränkung (x .. p) ist verträglich 
mit einer früheren Bereichseinschränkung (x 1 .. p'), falls 
gilt X' < X und p < p' oder falls X > p. 


2 , 1 , 1 . 1.1 DER AUFZÄHLUNGSTYP 


Durch Aufzählung von frei wählbaren Namen oder Zeichenkon¬ 
stanten kann ein Wertebereich und damit ein Typ definiert 
werden. 

Syntax: 

ADA 20: AZ TYP DEFINITION (AZ TYP DEF) 


-©- 


.O. 

- AZ KONSTANTEN NAME - 
)— ZEICHEN —Q- 

Lcte.*.aXkonitante. 


<!> 


Semanti k: 

Die aufgezählten AZ KONSTANTEn, das sind AZ KONSTANTENNAMEN 
oder Zeichenkonstanten, bilden einen Wertebereich; sie wer¬ 
den durch ihr Auftreten in der Aufzählung definiert und sind 
gemäß den Regeln der Blockstruktur wie definierte Größen zu 
behandeln. Eine AZ Konstante kann mehrfach belegt sein, d.h. 
in mehreren AZ Typdefinitionen auftreten. Die AZ Konstanten 
sind von links nach rechts durchnumeriert. Die Positionsnum¬ 
mer der ersten Konstanten ist 0. 


4 * 
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B.2 Vereinbarungen 


Die Typen boolean und character sind spezielle vordefinierte 
Aufzählungstypen. Da für sie mehr Operationen als für norma¬ 
le Aufzählungstypen bekannt sind, sind sie allerdings eigen¬ 
ständige Typen. 

Die Konstanten des AZ Typs sind in ADA 38 angegeben. 

Beispiel: 

type ehestand i_s (ledig,verhei ratet, geschieden »verwitwet); 
type Wochentag is_ (mo,di ,mi ,do,fr,sa,so); 
type tonart j_s (do,re,mi ,fa,so,la,si); 


2,1,1,1.2 DER TYP boolean 
type boolean j_s (FALSE,TRUE); 

Die Werte aller Vergleiche sind boolean. Boolesche Ausdrücke 
dienen zur Verzweigung in bedingten Anweisungen. 

Die Konstanten sind in ADA 36 angegeben. 


2,1.1.1,3 DER TYP character 

Der Typ character besteht aus allen 128 ASCII-Zeichen. Dabei 
gibt es (im Paket Standard) für die nicht druckbaren oder 
nicht zum Zeichensatz gehörigen Zeichen vorgeschriebene Kon¬ 
stantennamen. 

Die Konstanten sind in ADA 37 angegeben: 







2.1.1.1.4 Typ integer 
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ADA 37: CH KONSTANTE (CH KONST) 



:=u> 


CH TYP NAHE 

- A TYP NAHE 

- A VAR NAHE —. 

- A KONST NAHE -*-0- 


LgüD-O- 



Enquete (urfu> ote 
you, mi) 
Acknouledge 

Glockt (beti) 

Badupace 

TabutaXon 

ItUtnvoudwb Itine 
iitdl 

VvUical Tab 

SliXer.vo'UcJiub I {all 
*eed) 

Uagentücktaiti (cat- 
tiage teiutn) 
Shift out 

Shi.it in 
Vota Unk Escape 
Pevicc ConViol 1 
Pevice Contxol 7 
Pevice ConViol 3 
Pevice ConViol 4 
Higa.ti.vi Ac.knovite.dgt 
Synchtonoui Idle 


-dJED- 


-C 

m 


m 

- i 5h 

—cm 
mm 
<m 

— (l_br 
— (back 
— (r_br 
-(circ 


mm 


D- 

D- 

O- 

D- 

D~ 

> 

D- 


n> 


ÜD- 


üD- 

cket )— 

TäsT^— 

cket )— 


mfleifr - 

> 


> 

n> 

> 


Concc/ 

End o$ Medium 
SubitiXute 
Eicape, ptefix 
Fite Sepaiuito t 
Gtoup Sepa-tatot 
Recotd Sepototot 
Unit Sepaxa.to\ 
Petete 


2 . 1 . 1 . 1.4 DER TYP integer 


10118/16 ) Gtenze de. 
obete J CH Tgp. bzw. 

de. 1. Index- 
beteidie. 


Kteinbuchi toben 


Syntax: 


ADA 20: I TYP DEFINITION (I TYP DEF) 

-(r-I )- ränge - I EINF AUS ■ 


I EINF AUS • 
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B.2 Vereinbarungen 


Semantik: 

Alle Integertypen sind eingeschränkte Untertypen des fikti¬ 
ven, anonymen, unbeschränkten Typs universal_integer. Von die¬ 
sem Typ sind auch alle Integerkonstanten. 

Syntax: 


ADA 22: I TYP 

- ZUN — I TYP NAME 



ietbitde^hUenXen lnte.ge.ntyp 
v on.de &iniente lntegentypen 


att/UbutienXe lntegentypen 


L - I EINF AUS -Q- 1 EINF AUS 


X 


ßeneichi e-tni chnänkung 


Semantik: 

Jeder durch eine Typdefinition selbstdefinierte Integertyp 
ist Untertyp eines anonymen Typs,der von einem der vordefi¬ 
nierten Integertypen abgeleitet ist, d.h. also, der Basistyp 
ist nicht bekannt, der Übergang zu jedem anderen Integertyp 
hat deshalb explizit durch Typkonvertierung (siehe 3.10) zu 
erfolgen. Selbstverständlich sind alle Operationen und Kon¬ 
stanten vom Typ universal_integer bekannt. 

Die I Konstanten sind in ADA 39 angegeben. 


Beispiel: 

type zahl is ränge 3 .. 200; 
ist äquivalent zu 

subtype zahl i_s new short_integer ränge 3 .. 200; 

oder, falls der Typ short_integer nicht implementiert 
ist oder nicht bis 200 reicht, äquivalent zu 
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2.1.1.1.4 Typ integer 
subtype zahl is new integer ränge 3 .. 200; 
anonymer Typ 

Sei a ein eingeschränkter Arraytyp, Arrayvariable oder -kon¬ 
stante, < der Wert der Indexposition, so bezeichnet 
a'range(K) den Untertyp des <-ten Indexbereiches von a. 

Fehlt die Angabe der Indexposition, so ist automatisch k:= 1 
gesetzt. a'base'range(K) bezeichnet den Basistyp des K-ten 
Indexbereichs. Der Wert der Indexposition muß zur Überset¬ 
zungszeit berechenbar sein. 

Die vordefinierten Typen integer, short_integer und long_in- 
teger sind symmetrisch zu Null (bis auf eine zusätzliche ne¬ 
gative Zahl im Falle von b-1 Komplementdarstellung). Ihre 
Wertebereiche unterscheiden sich deutlich. Nur der Typ inte¬ 
ger ist für jede Implementierung vorgeschrieben. Der Typ na¬ 
tural ist der Untertyp aller positiven integer-Zahlen. 

subtype natural is_ integer ränge 1 .. integer'last; 

Der Typ priority ist ein implementierungsbedingter Untertyp 
von integer für die Priorität von Prozessen. 

Der implementierungsbedingte Typ file_index dient zur Angabe 
von Filepositionsnummern. 

Hinweise: 

(1) Die integer Typen gehören sowohl zu den skalaren als auch 
zu den numerischen Typen. Man kann sie also zur Indizie¬ 
rung gebrauchen und zu den reellen Typen konvertieren. 
Auch Typkonversionen zwischen den verschiedenen vordefi¬ 
nierten integer Typen sind möglich. Eine Konvertierung 
vom Typ universal_integer geschieht dagegen automatisch. 

(2) Die vordefinierten Integertypen bezeichnen wir in den 
Diagrammen mit folgenden Abkürzungen 
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B.2 Vereinbarungen 


integer 

short_integer, 1ong_integer 
natural 
priori ty 
file_index 

2.1,1.2 REELLE TYPEN 

Der Wertebereich eines reellen Typs ist eine maschinenunab¬ 
hängige Teilmenge der reellen Zahlen: die sogenannten Modell- 
zahlen. Jede Implementierung muß mindestens die Modell zahlen 
exakt darstellen. Die Rundung □ einer reellen Zahl (im ADA- 
Sprachgebrauch eines Wertes vom fiktiven anonymen Typ uni ver¬ 
sa l_real) in die Menge der Modell zahlen M hat folgende Eigen¬ 
schaften 

(RI) /\ □ x = x , d.h. Modell zahlen verändern sich durch die 
xeM 

Rundung nicht, sie werden exakt darge¬ 
stellt. 

(R2) Seien y und z die beiden unmittelbar benachbarten Mo¬ 
dell zahlen von x mit y < z. 

A ox e {y,z}, d.h. durch die Rundung werden alle 
x6 ^ ,z -* reellen Werte aus einem Model linter- 

vall [y,z] auf eine der Grenzen ab¬ 
gebildet. 



2.1.1.2.1 Gleitpunktyp 
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2 . 1 , 1 . 2,1 DER GLEITPUNKTTYP 


Syntax: 


ADA 20: 6 TYP DEFINITION (G TYP DEF) 


Lilü- I EINF AUS - 

Länge dei dezimalen M antiuc 


6 EINF AUS -Q- 


GEINF AUS 


un-teie Schlanke. \ 


oben Schlanke p 


Semantik: 

Sei 6 der Wert der Länge der dezimalen Mantisse. Dann ist die 
Modellmenge das Gleitpunktsystem M = G(ß,2,-4ß,4ß), d.h. die 
Menge aller Gleitpunktzahlen zur Basis 2 mit 
ß _> 6 * ln(10)/ln(2) Mantissenziffern und dem Exponentenbe¬ 
reich -4ß bis 43. (Die Werte der Länge der dezimalen Mantisse 
und der unteren und oberen Schranke) 6,X und p müssen zur 
Übersetzungszeit berechnet werden können. 


Hinweise: 

(1) Gleitpunktzahlen approximieren die reellen Zahlen mit 

relativer Genauigkeit, d.h. /\ [ x ~ - ° x -| < 2 1 ” 13 . 

X6[X,p] 

(2) Alle Modell zahlen sind von der Form y*2 n . 

Dabei ist y der Wert der dualen Mantisse und n der Wert 
des ganzzahligen Exponenten. Es gilt 
0.5 £ y < 1, 

-43 i n l 4ß, 

y hat ß Stellen nach dem Punkt 

(3) Durch ß, d.h. durch 6 wird also die Genauigkeit der Appro¬ 
ximation beschrieben. 

(4) Da das Dualsystem zur Beschreibung der maschinenunabhän¬ 
gigen Modell menge verwendet wird, in der Darstellung von 
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B.2 Vereinbarungen 


Konstanten im Programm jedoch meist das gewohnte Dezimal¬ 
system benutzt werden wird (s. 3.5.1), welches ja auch 
bei der Typdefinition bevorzugt wird, ist große Vorsicht 
bei Genauigkeitsfragen geboten. Denn durch automatische 
Konvertierung, die auch bei Dezi mal maschinen auftritt(!), 
können sich unbemerkt Fehler einschleichen. 

Beispiele: 

type gl ei tl i_s di gi ts 1 ränge 0.1 .. 1.0; 

beschreibt die Dezimal zahlen zwischen 0.1 und 1 mit einer 
Mantissenziffer: 

0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0 

In der Menge der zugehörigen Modell zahlen 
M = G(4,2,-8,8) n [0.1,1] 

liegen nur 0.5 und 1, während alle anderen Werte gerundet 
werden müssen, z.B. 

□ 0.3 = 0.1001 2 -1 = 0.28125 
oder □ 0.3 = 0.1010 2 -1 = 0.3125 

0.11002“3 = 0.09375 gehört zum Wertebereich des Typs, falls 
□ 0.1 = 0.09375 ist! 


Syntax: 

ADA 22: 6 TYP 


ZUN — G TYP NAHE — 


itlbitdiftinieAtUi Glcltpunkttyp 


—(TTöät)- 

— (short_float^ 


—(long_f loat^)— 


vonde. &inie.iUc. GteMtpunkttypcn 


- d i g 1 ts - 

- I EINF AUS -| 

T. 6{G,F) _ 

- ranae 1 T FI NF AUS T FI NF AUS- 


länge din. de.zi- 

mafen Mantme 

r oiiyc - • 2 Llllr nUO LI 111 MUo 

untere Schamtfee obcie. Schxajbc. 

Genauigk&lti e-i.it 4 c hlänkung 

BdA&ichi eXni c/t-tänkuitg 


l&tutlichii Amdiuck) 
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Semantik: 

Jeder durch eine Typdefinition selbstdefinierte Gleitpunkt¬ 
typ ist Untertyp eines anonymen Typs, der von einem der vor¬ 
definierten Gleitpunkttypen abgeleitet ist. Der Basistyp ist 
also unbekannt und kann je nach Implementierung ein anderer 
sein. 

(Die Ge.naulgkeJXA- und Be^ie^cc/u qJm ck^änkung^n bei Untertyp¬ 
oder VariablenVereinbarung müssen mit der des Basistyps ver¬ 
träglich sein.) Sei 6 die Länge der dezimalen Mantisse, X der 
Wert der unteren, p der Wert der oberen Schranke. Die ent¬ 
sprechenden Größen des Basistyps seien 6', X 1 , p'. Dann heißt 
die Genauigkeitseinschränkung des Untertyps verträg¬ 
lich mit der des Basistyps, falls 6 < 6 1 , die Bereichs¬ 
einschränkung heißt verträglich , falls X,p e~ 
U',P']. 

Jede Implementierung kennt den Typ float. Die Typen long_- 
float und short_float unterscheiden sich, falls vorhanden, 
deutlich in der Genauigkeitseinschränkung von diesem. 

Die Werte 6,x und p bei Untertyp- oder Variablenvereinbarung 
brauchen erst zur Laufzeit bekannt zu sein. 

Die G KONSTANTEN sind in ADA 40 angegeben. 

Hinweis: 

Durch eine Genauigkeitseinschränkung bei Untertypen wird eine 
geringere Genauigkeit verlangt als bei dem Grundtyp. Dadurch 
kann die Verarbeitungsgeschwindigkeit erhöht werden. Man kann 
nicht davon ausgehen, daß für jede Modell menge eine eigene 
Arithmetik implementiert ist, daß also eine Beschleunigung 
in jedem Fall eintritt. 
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B.2 Vereinbarungen 


Beispiel: 

type real i_s di gi ts 10; 
ist äquivalent zu 

subtype real j_s new float digits 10; 

falls die Genauigkeit von float 10 Dezimal Ziffern in der 

Mantisse zuläßt, sonst 

subtype real i£ new long_float digits 10; 


2,1,1.2,2 DER FESTPUNKTTYP 
Syntax: 

ADA 20: F TYP DEFINITION (F TYP DEF) 

T. e{G,F} T 6{G,F) t,6{G,F} 

- deita —- T, EINF AUS - ran^e £- r 2 EINF AUS —- T } EINF AUS - 

SchsUAtwiLte. untere. Schwanke. obe/ie Schwanke. 


Semantik: 

Der Wert 6 der ScktvcttweAXe. muß positiv sein und zur Überset¬ 
zungszeit berechenbar (statischer Ausdruck). 

Die Modell menge des Typs besteht aus aufeinanderfolgenden 
ganzzahligen Vielfachen einer implementierungsabhängigen 
Zahl A <_ 6. Sie ist symmetrisch zu Null, ungeachtet der Be¬ 
reichseinschränkung. Der Abstand der Schranken zur nächsten 
Modell zahl ist höchstens gleich 6. 

Hinweise: 

(1) Festpunktzahlen approximieren die reellen Zahlen mit ab¬ 
soluter Genauigkeit, d.h. /\ |x-nx| <_ A. 

xG[x,p] 

(2) a sollte bei Dualmaschinen eine Potenz von 2 sein. Sei 
a = -2 N + 1, 3 = 2 N - 1, dann besteht die Modellzahlen- 














2.1.1.2.2 Festpunkttyp 
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menge aus den Zahlen i*A, wobei i die ganzen Zahlen von 
a bis ß durchläuft. N ist dabei so gewählt, daß zwei 
ganze Zahlen v,y 6 [a,3] existieren, so daß gilt: 

|x - v»a| <_ 6 und |p - p-A| <_ 6. 


Beispiel: 

type fixl is delta 0.1 ränge 0.1 .. 1.25; 

beschreibt die Dezimal zahlen 0.1, 0.2, ...,1.0, 1.1, 1.2 . 

Die Menge der Modell zahlen bei dualer Maschine ist für diesen 
Bereich also 

M = {i-2 -4 11 = -2' 5 + 1 (1) 2‘ 5 -1} 

= {0.125, 0.1875, 0.25, 0.3125, 0.375, 0.4375, 0.5, 

0.5625, 0.625, 0.6875, 0.75, 0.8125, 0.875, 0.9375, 1, 
1.0625, 1.125, 1.1875, 1.25}. 


Syntax: 


ADA 22: F TYP 

ZUN — F TYP NAME — 

-(duratlon)- 


Semantik: 

Eine Genauigkeitseinschränkung (6) heißt verträglich mit ei¬ 
ner früheren (6 1 ), falls 6 _> 6', eine Bereichseinschränkung 
(A,p) heißt verträglich mit einer früheren (A',p'), falls 
A,p 6 [X',p 1 ]. Der vordefinierte Typ duration (D) dient zur 
Zeitangabe (in sec.) in Verzögerungsanweisungen (s. 9.4). 

Die F Konstanten sind in ADA 40 angegeben. 


ietbitdeiinieMen Fatpiuikttyp 
vorde diniertet Fa tpwibtti/p 


T. 6(6,F) 

M» - F EINF AUS 


Tj 6{G,F) 


? EINF AUS. -Q- T j EINF AUS - I 


Genauigkei ti e im chtänkung 


BeAeidu eim dinättkung 
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B.2 Vereinbarungen 


2.1.2 STRUKTURIERTE TYPEN 

Die Zusammenfassung von Werten aus beliebigen Datentypen 
kann aufgefaßt werden als Wert eines neuen Datentyps, der 
dann aus allen Werten besteht, die durch gleichartige Zusam¬ 
menfassung entstanden sind. Die Art der Zusammenfassung be¬ 
zeichnet man als Strukturierung, und dementsprechend heißt 
auch der Datentyp strukturiert. Es gibt in ADA 2 Formen 
strukturierter Datentypen 

- Felder oder Arrays 

- Verbünde oder Records 


2.1.2.1 DER ARRAY TYP 


Ein Feld (auch Array genannt) besteht aus einer festen An¬ 
zahl von Komponenten gleichen Typs. Die einzelnen Komponen¬ 
ten werden durch Indizes gekennzeichnet. Die Typdefinition 
eines Feldes enthält also Indexbereiche und den Komponenten¬ 
typ. 


Syntax: 

ADA 20: A TYP DEFINITION (A TYP DEF) 


unbeAcknänkten Indexbe-'uu.dt 


.O. 

T,60 n 

INDEX BER - 


■O 


T 2 60U{PZS}U<I> 


btechnänktzK Indcxbe'teicft 


£f — t 2 TYP - 

Kompone.ntc.ntyp 


Als Basis typen für Indexbereiche kommen alle diskreten 
Typen in Betracht. 

In einer Typdefinition müssen die Indexbereiche entweder 

















2.1.2.1 Array Typ 

alle unbeschränkt oder alle beschränkt sein. 
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Semantik: 

Ein Feld oder Array besteht aus einer durch die Indexbereiche 
festgelegten Anzahl von Komponenten des gleichen Typs. Mehr¬ 
dimensionale Arrays können als Arrays von Arrays aufgefaßt 
werden, jedoch hat die Indizierung (anders als in PASCAL) 
gemäß der Typdefinition zu erfolgen. 

Nur in einer Typvereinbarung darf eine Array Typdefinition 
mit unbeschränkten Indexbereichen stehen. 

Korrekte Komponentenzugriffe sind 

z.B. A: array (1 .. 10) of array (1 .. 10) of integer; 

B: array (1 .. 10, 1 .. 10) of integer; 

A(1)(3), aber B(l,3) und nicht B(1)(3) 

Syntax: 


ADA 47: t INDEX BEREICH (t INDEX BER) Teo 0 

Gq » {B,CH,AZ , I) 


- r TYP NAME 

- t TYP NAME 

IndcxXyp 


ränge X r EINF AUS —0- T EINF AUS 




ünte*e Grenze 


Semantik: 

Ist ein Indexbereich leer (s. 2.1.1.1), so hat das Feld keine 
Komponenten. 

Fehlt für T = I die Angabe des Typnamens, so wird integer als 
Basistyp genommen. Der Wert der Grenzen braucht erst zur Lauf¬ 
zeit berechnet werden zu können. Man spricht dann von dynami¬ 
schen Arrays. 

Der Wert der Grenzen muß innerhalb des Wertebereichs des In¬ 
dextyps liegen. 
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B.2 Vereinbarungen 


Syntax: 


ADA 22: A TYP 


•ZUN — t TYP NAME 


KA-ST)- 


—(strlng)— 


— f.O.: 

JÄ*"“ LqI W r, INDEX BER-m> 


I «dexbcAexc/w utu clifi&nkung 

Semanti k: 

Eine Indexbereichseinschränkung betrifft stets alle Indizes. 
Ein Array Typ mit beschränktem Indexbereich darf keine weite¬ 
re Indexbereichseinschränkung erfahren. 

In einer Variablenvereinbarung muß ein Array Typ mit be¬ 
schränktem (möglicherweise dynamischem) Indexbereich angege¬ 
ben werden. Treten dynamische Arrays in Records auf, so müs¬ 
sen die Grenzen Diskriminanten sein (s. 2.1.2.2). 

Beispiel: 

type vektor i_s array (1 .. 100) of i nteger; 
subtype halb vektor i_s vektor (1 .. 50); 
ist unzulässig 

type v i_s array (integer ränge <>) of integer; 
subtype vektor is v (1 .. 100); 
subtype halbvektor i_s v (1 .. 50); 
ist korrekt 


2 . 1 . 2 . 1.1 DER STRING TYP 

Der String Typ ist ein vordefinierter eindimensionaler unbe¬ 
schränkter Array Typ mit Komponententyp character. 



























2.1.2.2 Record Typ 
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type string j_s array (natural ränge <>) of character; 

Da für diesen Typ spezielle Operationen vorgesehen sind und 
er als Ergebnistyo attributierter Funktionen vorkommt, wird 
er an manchen Stellen besonders erwähnt. 

Die ST Konstanten sind in ADA 42 angegeben. 


2.1,2,2 DER RECORD TYP 

Ein Record (Verbund) besteht aus endlich vielen Komponenten, 
die von verschiedenem Typ sein können. Die Komponenten werden 
durch ihren Namen angesprochen. 

Syntax: 

ADA 20: REC TYP DEFINITION (REC TYP DEF) 

- record - DSL - end - record - 


ADA 21: DATENSATZLISTE (DSL) 

0 = { B,CH,AZ,I,G,F,A,ST,REC,Z) » - (IF,OF , IOF,ITF,OTF) e 0 • (B.CH.AZ.t) 



Semantik: 

Ist die Datensatzliste nul1 , so hat das Record keine Komponen¬ 
ten. 

Hat die Datensatzliste in einer RECORD TYP DEFINITION keinen 


5 Kaucher IV - ADA 
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B.2 Vereinbarungen 


VaAlantzntM, so haben alle Objekte dieses Typs die glei¬ 
chen Komponenten. 

In der A TYP DEF dürfen nur eingeschränkte Indexbereiche Vor¬ 
kommen, die Grenzen müssen entweder zur Übersetzungszeit be¬ 
rechnet werden können (statische Arrays) oder formale Diskri- 
minanten des Record Typs sein (dynamische Arrays). Es dürfen 
jedoch keine Ausdrücke mit den formalen Diskriminanten gebil¬ 
det werden. 

Die Datensatzliste al,a2,a3: a; ist äquivalent zu der Daten¬ 
satzliste al: a; a2: a; a3: a; Die Auswahlmarke ist eine 
formale Diskriminante. Die statischen Auswahlausdrücke müssen 
jeden Wert des entsprechenden Diskriminantentyps genau einmal 
annehmen, oder ein others -Zweig muß vorhanden sein. 

Beispiele: 
type geld is 

record mark : integer; pfennig : ränge 0..99; 
end record ; 
type fahrrad is 

record marke : String (1..20); 

rahmenhoehe : de!ta 0.5 ränge 50..65; 
gangzahl : integer ränge 1..18; 
preis : geld; 
end record ; 

Hinweis: 


Durch Angabe von Ausdrücken zur Initialisierung der einzelnen 
Komponenten kann man eine Standardvorbesetzung für den gesam¬ 
ten Recordtyp erreichen. 

Wie in PASCAL tritt maximal ein Variantentei1 am Schluß auf. 
Dieser kann selbstverständlich wieder Variantenteile enthal¬ 
ten, usw. 














2.1.2.2 Record Typ 
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Anders als in PASCAL muß die Auswahl marke einen Namen haben. 
Zur Auswahl der Varianten können auch Bereiche herangezogen 
werden. Alle Werte des Diskriminantentyps müssen angenommen 
werden. Notfalls können nicht gebrauchte mit others nul1 ; zu¬ 
sammengefaßt werden. 

Eine Recordtypvereinbarung kann eine formale Diskriminanten¬ 
liste beinhalten. 

Syntax: REC TYP VEREINBARUNG aus ADA 18 VEREINBARUNG 


- tz£e —REC TYP NAME- 


- FOR DISKR LISTE -j 

_ <, . _ orr TY n ncr 


11 1 Tl ULI 

[unvotl&t. TijpveAeAJib .) 


ADA 19: FORMALE DISKRIMINANTENLISTE (FOR DISKR L) 

e D = (b,ch,az, i) 

.O. 

I.o- 


- T DISKR NAME 


■ t TYP - 


-0— t AUSDR 


1 


<D- 


Semantik: 

Entweder werden alle Diskriminanten initialisiert oder keine. 


Syntax: 


ADA 22: REC TYP 


— ZUN —REC TYP NAME- 


- AKT DISKR LISTE - 


ADA 32: AKTUELLE DISKRIMINANTENLISTE (AKT DISKR LISTE) 

ü 0 = {B,CH,AZ,I} 


•o 


• T AUSDR ■ 


•Q- 


.©-• 

t DISKR NAHE - 


-0- 7 AUSDR ■ 


<D— 


MUuetle Vi&knÄminanten 
in R eihenfolge de a ioimalen 


in betiebigex Reihenfolge 


Home formale/. 
Diikximinante 
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B.2 Vereinbarungen 


Semantik: 

In der aktuellen Diskriminantenliste wird jeder ionmalm Vh>- 
knlminante, ein Wert des entsprechenden Typs zugewiesen. Es 
gibt zwei Möglichkeiten der Ersetzung; entweder werden die 
aktue,llm ViAknlminantm der RelkmioZge. nach zugewiesen, 
oder es werden die Namen der formalen Diskriminanten wieder¬ 
holt {batLzbiga Rzlkmiolge.). Diese beiden Arten können ge¬ 
mischt werden, dann muß jedoch die Ersetzung nach Namen am 
Schluß stehen. 

Die Angabe einer aktuellen Diskriminantenliste schränkt den 
Wertevorrat aller Objekte des Typs auf die durch die angege¬ 
benen Diskriminanten bestimmten Records ein. Sie kann später 
nicht durch Angabe einer weiteren Diskriminantenliste umde¬ 
finiert werden. Fehlt die Initialisierung in der formalen 
Diskriminantenliste, so muß bei einer Variablen- oder Kon¬ 
stantenvereinbarung sowie bei einer Typangabe für den Kompo¬ 
nententyp eines Records oder Arrays eine aktuelle Diskrimi¬ 
nantenliste stehen. 

Hinweis: 

Durch eine Diskriminantenliste läßt sich ein Record Typ para- 
metrisieren. Bis zur VariablenVereinbarung muß diese Paramet¬ 
risierung allerdings durch Angabe aktueller Diskriminanten 
aufgehoben sein. Der Wechsel der Varianten, wie in PASCAL 
vielfach zu Tricks mißbraucht, ist also hier nicht möglich. 

Beispiele: 

1. Im folgenden wird der Record Typ Peripherie mit Varian¬ 
tenteil vereinbart. Die Auswahl der Variante erfolgt 
über die Diskriminante einheit vom Typ geraet: (aus [1]) 

type geraet j_s (drucker,platte,trommel); 
type Status is^ (offen,zu); 





2.1.2.2 Record Typ 
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type peripherie (einheit : geraet := platte) is 
record 

zustand : Status; 
case einheit is 
when drucker => 

Zeilenzahl : integer ränge 1..seitenlaenge; 
when others => 

Zylinder : index; 
spur : nummer; 
end case ; 
end record ; 

Die Vereinbarung 

subtype druck_peripherie i_s peripherie (drucker); 
kann auch durch 

type druck_peripherie is 
record 

zustand : Status; 

Zeilenzahl : integer ränge 1 .. seitenlaenge; 
end record ; 
dargestellt werden. 

2. Im folgenden wird der Record Typ fuehrerschein mit Vari¬ 
antenteil vereinbart. Die Auswahl der Variante erfolgt 
über die Diskriminante amtliches vom Typ eintragungen: 

type name is 

record vorname : String (1..10); 

zweiter_vorname : character; 
nachname : String (1..10); 
end record ; 

type klasse j_s (IA,IB,II ,111 ,IV); 
type monat_name i s 

(jan,feb,mae,apr,mai,jun,jul ,aug,sep,okt,nov,dez); 
type datum 
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B.2 Vereinbarungen 


record tag : integer ränge 1..31; 
monat : monat_name; 
jahr : integer; 
end record ; 
type eintragungen 

(normal,eingeschraenkt,spezi al_erl aubnis,vip); 
type fuehrerschein (amtliches : eintragungen) is 
record fahrer : name; 

fuehrerschein_klasse : klasse; 
fuehrerschein_nummer : integer; 
ausstellungs_datum : datum; 
case amtliches is 

when spezial_erlaubnis => 
fahrzeug_typ : integer; 

Passagiere : boolean; 
zonen_nummer : integer; 
when eingeschraenkt => 
kontaktlinsen : boolean; 
nicht_bei_dunkel heit : boolean; 
nur_automatik getriebe : boolean; 
when others => null ; 
end case ; 
end record; 


2.1.3 DER ZEIGERTYP 

Unter den bisher behandelten Datentypen vermissen wir zwei 
wesentliche Eigenschaften: 

(1) Eine Variable sollte während der Ausführung eines Blok- 
kes, falls sie benötigt wird, erzeugt werden können. 

(2) Eine unbestimmte Anzahl von Elementen, z.B. eine Kartei, 
















2.1.3 Zeigertyp 
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sollte auf einfache Weise bearbeitet werden können. Ins¬ 
besondere sollte das Anfügen, Einfügen, Herausnehmen (Lö¬ 
schen) von Elementen leicht möglich sein. 

Diese Lücke füllt die Zeigervariable. Dabei ist eine Zeiger¬ 
variable z ein Zeiger (Verweis, Zugriff), der auf eine Vari¬ 
able z. al1 des sogenannten referierten Typs verweist. Diese 
referierte Variable wird erst während der Ausführung einer 
Programmeinheit durch die Speicherbelegungsfunktion (Alloka- 
tor) new generiert (dynamische Variable), während die Zeiger¬ 
variable selbst wie Variablen aller anderen Typen vereinbart 
werden muß (statische Variable). Damit kann man nahezu alle 
erwünschten Datenstrukturen wie lineare Listen, Bäume, ... 
usw. erzeugen. 

Ein Zeiger, der auf eine Variable eines bestimmten Typs ver¬ 
weist, ist vorstellbar als Adresse (Speicherplatznummer) 
dieser Variablen. Der Typ dieser Variablen, der sogenannte 
Typ, ist bei der Zeigertypdefinition anzugeben. 

Syntax: 


ADA 20: Z TYP DEFINITION (Z TYP DEF) 

T,60U{PZS)U* 

- access - Tj TYP — 

’ttit'UeAXv t Typ 


Semantik: 

Der Wertebereich eines Zeigertyps ist die Menge der Verweise 
auf Variable vom referierten Typ, erweitert um den Wert nul1 , 
einem konstanten Zeiger, der zu jedem Zeigertyp gehört und 
auf keine Variable verweist, nul1 ist der Standardanfangs¬ 
wert aller Zeigervariablen. 

Für Zeigertypen und strukturierte Typen, die Zeigertypen ent¬ 
halten, kann die unvollständige Typvereinbarung auftreten. 

Sie ist zu verwenden, falls der referierte Typ Komponenten 
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B.2 Vereinbarungen 


des vereinbarten Zeigertyps enthält. Mit ihrer Hilfe lassen 
sich also rekursive und gegenseitig abhängige Datenstruktu¬ 
ren formulieren unter der Bedingung, daß jede Größe bekannt 
sein muß, falls sie verwendet wird. Eine vollständige Typ¬ 
vereinbarung eines unvollständig vereinbarten Typs hat noch 
im gleichen Vereinbarungstei 1 zu folgen. 


AUS ADA 18: VEREINBARUNG 


unvoll&t. Ti/pveteinbatung 


- t/£e — r TYP NAME 


r 


Rieb FOR DISKR LISTE -i 


• Ü — t TYP DEF • 


Beispiel: Unvollständige Typvereinbarung 

type zeigerpaar; 

type el 1 j_s record i : integer; 

p : zeigerpaar; 
end record ; 

type p2; 

type el2 is record i : character; 

p: p2; 

end record ; 
type d2 js. access el 2; 
type pl ij^ access el 1; 
type zeigerpaar is record zl : pl; 

z2 : p2; 
end record ; 


Syntax: 

ADA 22: Z TYP 








































2.1.4 Untertypen 
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Semantik: 

Die Indexeinschränkung bzw. aktuelle Diskriminantenliste be¬ 
zieht sich auf den referierten Typ. Sie muß spätestens bei 
der Generierung der dynamischen Variablen durch die Spei¬ 
cherbelegungsfunktion new angegeben werden (vgl. Array- bzw. 
Recordtyp). 


2,1,4 UNTERTYPEN 

Es gibt in ADA die Möglichkeit, Untertypen zu vorliegenden 
Typen, die dann als Basistypen bezeichnet werden, zu defi¬ 
nieren. Das wird in der Regel dazu benutzt, Werteberei che 
einzuschränken oder die Genauigkeit bei reellen Typen herab¬ 
zusetzen. 

Syntax: 


Aus 


ADA 18: VEREINBARUNG (VEREINB) 


r 60 u» 


subtype - T TYP NAME 


— 1YP ,~ 
Typangabt 


Semantik: 

Enthält die Typangabe, keine Einschränkung, so wird ein neuer, 
weiterer Name für den Basistyp (Muttertyp) eingeführt. Tre¬ 
ten Einschränkungen des Basistyps auf, so müssen sie mit den 
bereits bestehenden Einschränkungen verträglich sein. 

Basistyp und Untertyp sind k o m p a t i bei , d.h. es 
können die Werte der beiden Typen ohne Konversion verwen¬ 
det werden. 

Bei spiele: 

subtype temperatur j_s float digits 4 ränge -275.0.. 1.0e9; 
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subtype badetemperatur 21 temperatur ränge 15.0..48.0; 

Der Typ badetemperatur ist mit dem Typ temperatur kompatibel. 
Durch 

subtype taxi_fuehrerschein i_s 

fuehrerschein (amtliches => spezial_erlaubnis); 

wird ein Untertyp des in 2.1.2.2 beschriebenen Record Typs 
"fuehrerschein" vereinbart. 

Hinweis: 

Es können Untertypen von Untertypen vereinbart werden. 

Wir unterscheiden im folgenden nicht zwischen Basis typ und 
Untertyp, falls dies nicht ausdrücklich betont wird. 


2,1.5 ABGELEITETE TYPEN 

Neben den Untertypen gibt es noch die Möglichkeit, abgelei¬ 
tete Typen eines Basistyps zu definieren. Hier handelt es 
sich um einen neuen Typ, der im wesentlichen eine Kopie des 
Basistyps darstellt. 

Syntax: 


AUS ADA 20: t TYP DEFINITION (r TYP DEF) r e e u « 


new 


- t TYP • 

Buistyp 


Semantik: 

Es wird ein neuer Typ der gleichen Typklasse eingeführt 
(deshalb das gleiche Symbol T), für den bis auf eventuelle 
Einschränkungen des Wertebereichs oder Lockerungen der Ge¬ 
nauigkeitsforderungen bei reellen Typen folgendes gilt: 
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- Der Wertebereich ist eine Kopie des Wertebereichs des Ba- 
sistyps. 

- Die vordefinierten Anfangswerte des Basistyps werden über¬ 
nommen, falls vorhanden. 

- Basistyp und abgeleiteter Typ sind inkompatibel, jedoch 
besteht in beiden Richtungen die Möglichkeit der Typkon¬ 
version. 

- Die Schreibweise aller Konstanten und Komponenten ist die 
gleiche. 

-Alle Attribute und Darstellungsangaben werden übernommen. 

- Bei Zeigertypen besitzen der Basistyp und der abgeleitete 
Typ dieselben Wertebereiche. 

-Alle Operatoren, Funktionen und Prozeduren, die für den 
Basistyp vereinbart sind, oder in deren Argumentliste der 
Basistyp auftritt, stehen als abgeleitete Operatoren, 
Funktionen oder Prozeduren auch für den abgeleiteten Typ 
zur Verfügung. 

Der Aufruf eines solchen abgeleiteten Unterprogramms (Ope¬ 
rator, Funktion oder Prozedur) geschieht durch implizite 
Konversion der Eingabeargumente, Aufruf des Unterprogramms 
für den Basistyp und implizite Konversion der Ausgabeargu¬ 
mente. Die abgeleiteten Unterprogramme können für den ab¬ 
geleiteten Typ neu definiert werden. 

Hinweise: 

(1) Es können abgeleitete Typen von abgeleiteten Typen ge¬ 
bildet werden. 

(2) Für die Standardtypen und die vorgegebenen Operatoren 
gelten die gleichen Regeln. 

(3) Die abgeleitete Typdefinition ermöglicht es, verschie¬ 
dene Operatoren für den "gleichen" Typ zu vereinbaren, 
z.B. Addition von Gleitpunktzahlen mit Rundung nach 
oben oder nach unten. 
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Beispiel: Kompatibilität von Typen 

type zl is ränge -100 .. 100; 

type z2 i_s new integer ränge -100 .. 100; 

type z3 is^ new zl; 

subtype z4 j_s zl; 

zl, z2, z3 sind inkompatibel, zl und z4 sind zwei Namen für 
den selben Typ. Der Übergang von zl nach z2 bzw. nach z3 
kann mittels Konversion erfolgen. 


2 . 1.6 GESCHÜTZTE TYPEN 


In einem Paket sind Datentypen und Operationen zusammenge¬ 
faßt, die an anderen Stellen des Programms benutzt werden. 
Dabei ist die innere Struktur der verwendeten Datentypen oft 
nicht interessant. Zum Beispiel ist es unerheblich, ob eine 
komplexe Zahl mit Hilfe eines Arrays oder eines Records dar- 
gestellt wird, oder wie eine Liste aufgebaut ist, für die 
die benötigten Operationen "einfügen", "suchen" und "lö¬ 
schen" bekannt sind. Mit der Definition von geschützten Ty¬ 
pen kann man die Information über die innere Struktur ver¬ 
bergen. Besonders wichtig ist das Geheimhalten von Informa¬ 
tionen bei der Erstellung und Handhabung von Datenbanken, 
etwa Personalkarteien, wo dem außenstehenden Benutzer nur 
gewisse Teile der persönlichen Daten zugänglich sein dürfen. 

Syntax: 

Aus 

ADA 20: T TYP DEFINITION <t TYP DEF) r e e u * 


K Teö )- 


tbnUÄ.z'Utn. 


private 


guchiitzteA. Typ 

















2.1.6 Geschützte Typen 


77 


Semantik: 

Die Vereinbarung von geschützten Typen kann nur im sichtba¬ 
ren Teil einer Paketvereinbarung auftreten. Es wird nur der 
Name des geschützten Typs eingeführt. Die eigentliche Defi¬ 
nition des Typs muß in einer Typvereinbarung im geschützten 
Teil der Paketvereinbarung nachgeholt werden. Beeinhaltet 
die Typvereinbarung eines geschützten Typs eine formale Dis- 
kriminantenliste, so muß auch die entsprechende Vereinba¬ 
rung im geschützten Teil eine bis auf die Schreibweise der 
Diskriminantennamen identische formale Diskriminantenliste 
enthalten. 

Für einen geschützten Typ stehen nur die Zuweisung sowie 
die Vergleichsoperatoren = und /= zur Verfügung, für einen 
limitierten geschützten Typ noch nicht einmal diese. Des¬ 
halb dürfen für limitierte geschützte Typen außerhalb des 
Paketes, in dem sie definiert werden, 

- keine Konstanten vereinbart werden, 

- keine Initialisierung von Variablen oder Vorbesetzung von 
Parametern durchgeführt werden. 

Beispiele: 

1. package komplexe_ari thmetik is 
type complex j_s private; 

— Spezifikation komplexer Operationen und 
— Funktionen 

private type complex is^ record re,im : float; 

end record ; 

In diesem Paket wird der Typ complex als geschützter 
Typ vereinbart. Damit kann man außerhalb des Paketes 
komplexe_arithmetik z.B. nicht auf Real- oder Imaginär¬ 
teil von Objekten mit dem Typ complex zugreifen. 
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2, package optimale_arithmetik is 

type dotprecision i_s 1 imited private ; 

private type dot_precision J_s ... 

Der Typ dot_precision ermöglicht die exakte Berechnung 
von Skalarprodukten. Außerhalb des Paketes ist z.B. kei¬ 
ne Zuweisung für diesen Typ möglich. 

Hinweis: 

Ein Prozeßtyp kann als limitierter geschützter Typ verein¬ 
bart werden. 


2,2 DIE VEREINBARUNG VON VARIABLEN UND KONSTANTEN 


Syntax: 

Aus 

ADA 18: VEREINBARUNG (VEREINB) 



Semantik: 


- Es werden die Namen der Variablen oder Konstanten einge¬ 
führt, anschließend wird der Typ oder die Arraytypdefini- 
tion ausgewertet. Dann wird der An&angAu)QA£ berechnet und 
der Variablen oder Konstanten zugewiesen. 
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Fehlt die Initialisierung und gibt es für den Typ keine 
Standardinitialisierung, so ist der Wert der Variablen un¬ 
bestimmt. 

Die Anfangswerte müssen zur Laufzeit berechnet werden kön¬ 
nen. Die Anfangswerte für numerische Konstanten, also Kon¬ 
stanten ohne Typangaben, dürfen nur konstante Zahlen und 
für diese vorhandene vordefinierte Operationen verwenden. 
Der Typ ist entweder universal integer bzw. universal_real, 
d.h. eine implizite Konvertierung nach integer bzw. Gleit¬ 
oder Festpunkt ist gewährleistet. 

Der Wert einer Konstante darf im Programm nicht verändert 
werden. 

Variable vom Array Typ müssen beschränkte Indexbereiche 
haben. Entweder muß die Indexeinschränkung an den Typnamen 
eines unbeschränkten Arrays angefügt werden oder, falls 
der Array Typ explizit definiert wird, dürfen nur be¬ 
schränkte Indexbereiche auftreten. 

ADA 20: A TYP DEFINITION (A TYP DEF) 


— array -(T)- 


biAchAäniUeA Inaexbe'i&cc/i Kompon&ntenXi/p 


.^. 

ZUN — Tj TYP NAME — ra^i 

unbeactaän&te'i Itidexoe'ietc/t 

.O. 


• T. INDEX BER - 




- of — t 2 TYP ■ 


Für Konstante vom geschützten Typ hat die Initialisierung 
im geschützten Teil des Paketes zu erfolgen. 

Für Variable vom Record Typ muß eine aktuelle Diskriminan¬ 
tenliste angegeben werden, falls die formalen Diskriminan¬ 
ten nicht mit Anfangswerten initialisiert wurden. Die Dis¬ 
kriminanten können nur durch eine komplette Recordzuwei¬ 
sung verändert werden. 
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- Mit der Vereinbarung von Variablen bzw. Konstanten vom 
Array- oder Recordtyp sind gleichzeitig Komponentenvaria- 
blen (bzw. -konstanten) vom Typ der Komponente vereinbart. 
Eine Komponentenvariable bzw. -konstante eines Arrays mit 
Komponententyp T hat einen symbolischen Namen der Form: 

(aus ADA 33 und 48) 


T A KONST —| |.O.• 

A VAR-1- 0 68 ° T t AUSDR--— 0- 


-i— ST KONST 

I-ST VAR-1-©- I AUSDR-©— 


Eine Komponentenvariable bzw. -konstante eines Records hat 
einen symbolischen Namen der Form: 

(aus ADA 33 und 48) 


T 


REC KONST —| 
REC VAR —L 


0- t KOMP NAME- 


Mit der Vereinbarung von Variablen bzw. Konstanten vom 
Zeigertyp ist automatisch eine Variable vom referierten 
Typ mit dem Namen 


-r- Z KONST 
L 2 VAR-L 


o——■ 


(aus ADA 33 und 48) 
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vereinbart. Man beachte, daß auch im Falle einer Zeiger¬ 
konstanten der Wert des referierten Typs verändert werden 
kann, also variabel ist. 

- Verweist eine Zeigervariable oder -konstante auf ein Array 
oder Record, so sind Komponentenvariable mit dem oben an¬ 
gegebenen symbolischen Namen gleichzeitig mitvereinbart. 


I 


Z KONST -j 
Z VAR- 


O- 


•O. 

t, AUSDR — 
t KOMP NAME 



- Bei eindimensionalen Arrays, also auch Strings besteht die 
Möglichkeit, Teilfelder (Ausschnitte: slices) anzusprechen 
und damit Variable bzw. Konstante vom gleichen Array Typ 
mit anderen Indexgrenzen zu erhalten. 

aus ADA 33 und 48: 


r 


A KONST 

A VAR-L©— r INDEX BER 


- Entsprechendes gilt für Zeiger auf eindimensionale Arrays. 

Beispiel: 

Variable: 

x,y : float := 0.0; 
tl,t2 : badetemperatur; 
a : Peripherie (drucker); 

b : Peripherie; -- Diskriminante mit Platte 
-- initialisiert 
z : array (1..10,1..10) of float; 


6 Kaucher IV - ADA 
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Mit der Variable 
v : array (-18..307) of integer; 

ist v(0..10) die Vektorabschnittvariable mit den Komponenten 
0 bis 10. 

Konstanten: 

c : constant 1.5; 

blank : constant character := 

Komponentenkonstante: 

m : constant array (1..2) of array (1..2) of geld 

:= (((mark => 1,pfennig => 1),(2,2)),((3,3),(4,4))); 
reihe : constant array (1..5) of integer := (1,2,3,4,5); 

— reihe(l) ist eine integer Konstante mit Wert 1; 

-- m(l)(2) ist eine Konstante vom Typ geld, wobei die 

— Record Komponenten mark und pfennig jeweils den Wert 2 
-- haben. 


2.3 DIE VEREINBARUNG VON UNTERPROGRAMMEN 

Die Vereinbarung von Unterprogrammen wurde einführend schon 
in 1.1 besprochen. Die vollständige Beschreibung erfolgt im 
Zusammenhang mit der Handhabung von Unterprogrammen in 5.1. 


2.4 DIE VEREINBARUNG VON PAKETEN 


Die Vereinbarung von Paketen wurde in 1.2 behandelt. 
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2.5 DIE VEREINBARUNG VON UNTERPROGRAMM- UND 
PAKETSCHEMATA 

Von Unterprogrammen oder Paketen können auch sogenannte 
Schemata vereinbart werden, aus denen zur Übersetzungszeit 
entsprechende Unterprogramme oder Pakete ausgeprägt werden 
können (siehe 6). 


2.6 DIE VEREINBARUNG VON PROZESSEN 


Prozesse sind Programmeinheiten, mit deren Hilfe die paral¬ 
lele Verarbeitung von Programmstücken innerhalb eines Pro¬ 
grammes ermöglicht wird. Prozesse sind Objekte eines Prozeß¬ 
typs und werden daher wie Variable vereinbart. Der Wert ei¬ 
ner Prozeßvariable ist also ein Prozeß vom angegebenen Pro¬ 
zeßtyp. Entsprechend dem Diagramm ADA 1 sind Prozesse nur 
als UvitzhQAJili 2 jjtQ.n getrennt übersetzbare Programmeinhei ten 
(übe,sue.£zung 6 eA.nk 2 AÄ&n ). Eine ausführliche Beschreibung der 
Handhabung von Prozessen findet man in Abschnitt 9. 

Die Vereinbarung eines Prozeßtyps besteht aus einer PROZESS¬ 
SPEZIFIKATION und einem nachfolgenden PROZESSRUMPF mit dem 
gleichen Prozeßtypnamen. 

Syntax: 

ADA 15: PROZESSSPEZIFIKATION 




type — PZS TYP NAME —, 
- PZS VAR NAME 


- ENTRY VEREINB 


■ DARST ANG - 


Pio zeßtifpspc zi$i kation 
Pwzeßipe zi Sination 


- PZS TYP NAME 


- PZS VAR NAME - 


Auszählung deA Eingänge du 
P'iozcSüjpi bzw. Phozuau 


6* 
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ADA 14: PROZESSRUMPF 


— task-bod* , pzs TYP NAME 


1 


PZS VAR NAME 1 js T VEREINBTL 


*1 



ANW 


I 


exceptlon 


y AUSN BtHTL —j 


AUSN BEHTL 


end j- PZS VAR NAME n 
_, - PZS TYP NAME - 


Semantik: 

Durch eine ?Mze.ßtyp!>pe.zi( i ikcLtLon wird zunächst der Name für 
einen Prozeßtyp eingeführt und anschließend dessen Eingänge 
(siehe 9.2.1) gemäß den ENTRY VEREINBARUNGen und DARSTEL- 
LUNGSANGABEn festgelegt. Diese Eingänge bezeichnen die 
Schnittstellen zwischen Prozessen dieses Typs und anderen 
Prozessen gleichen oder anderen Typs. 

Eine VnozafopazlhikcutLoYi ist äquivalent zu einer Ptioz&ß- 
typ^pzzl^lkoution mit einem anonymen Typ und anschließender 
Vereinbarung einer Prozeßvariablen zu diesem Typ. Bei dieser 
Form der Spezifikation existiert also nur ein Objekt vom 
angegebenen anonymen Typ. 

Ein PROZESSRUMPF beschreibt die Aktionen für alle Prozesse 
eines Prozeßtyps. Insbesondere enthält er die für die Kommu¬ 
nikation mit anderen Prozessen notwendigen Schnittstellen, 
welche durch accept-Anweisungen festgelegt werden. 

Hinweise: 

(1) Operationen, Vergleiche oder Zuweisungen sind für Pro¬ 
zesse nicht möglich. Deshalb ist ein Prozeß eigentlich 
eine Konstante. 

(2) Prozeßtypen können als Komponenten von strukturierten 
Datentypen oder als referierte Typen von Zeigertypen 
auftreten. 
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(3) Prozesse können als Eingabeargumente in Unterprogrammen 
auftreten. Sie können als limitierte, geschützte Typen 
erscheinen, deren Definition im geschützten Teil gege¬ 
ben ist, und sie können anstelle von limitierten, ge¬ 
schützten Typen als aktuelle Schemaargumente übergeben 
werden. 

(4) Auf Prozeßtypen sind keine Beschränkungen anwendbar. 


2.7 DIE AUSNAHMEVEREINBARUNG 

Die Vereinbarung von Ausnahmen wird in 7. im Zusammenhang 
mit der Behandlung von Ausnahmen besprochen. 


2.8 UMBENENNUNGEN 

Für bekannte Größen können weitere Namen vereinbart werden. 

Syntax: 

Aus 

ADA 18: VEREINBARUNG (VEREINB) 


neuen Harne 

- r KONST NAME - 

- t VAR NAME — 

• AUSNAHME NAME - 

- package - 

. task - 


Tj/pnngabe 


-©- ZUN — T TYP NAME — renames — T KONST - 

-Q - ZUN — r TYP NAME — renames — T VAR — 


- exception — renames — ZUN — AUSNAHME NAME - 

- PAK NAME — renames - ZUN — PAK NAME - 

- PZS NAME- renames - PZS VAR - 


- UPG SPEZIF - renames - ZUN 


- PZD NAME - 

- ENTRY — 


• t FKT NAME - 
t OPERATOR - 


He%u(G.F,ST})- 


t ATTR FKT NAME - 


Umbennung 

von 

Koni tonten 

Vaxiabten 

Aui nahmen 

Paketen 

Pnozu&en 

Pnozeduxen 

öden 

Eingängen 









































86 


B.2 Vereinbarungen 


Semantik: 

Der vor dem Wortsymbol renames (bzw. bei Konstanten, Variab¬ 
len und Ausnahmen vor dem Doppelpunkt) stehende Name wird 
als neuer Name für die hinter renames stehende Größe einge¬ 
führt. Bei der Umbenennung von Unterprogrammen wird die ge¬ 
samte Unterprogrammspezifikation verarbeitet. 

Es sind folgende Punkte zu beachten: 

- Bei Umbenennung von Konstanten und Variablen muß die Typ¬ 
angabe den gleichen Einschränkungen unterliegen wie die 
umbenannte Größe. Eine Komponente eines uneingeschränkten 
Record Typs kann nicht umbenannt werden, falls ihre Exi¬ 
stenz von einer Diskriminante abhängt. 

- Bei der Umbenennung von Unterprogrammen muß die neue for¬ 
male Argumentliste die gleichen Ein- und Ausgabeargumente 
in der gleichen Reihenfolge wie das umbenannte Unterpro¬ 
gramm haben. Funktionen müssen gleichen Ergebnis typ haben. 
Namen der Argumente sowie eventuell vorliegende Initiali¬ 
sierungen können verschieden sein. 

- Eine Funktion kann als Operator umbenannt werden und umge¬ 
kehrt. 

- Ein Eingang kann in eine Prozedur umbenannt werden. 

- Bei überladenen Unterprogrammnamen darf nur einer mit der 
neuen Unterprogrammspezifikation übereinstimmen. 


Beispiele: 

alpha : float renames x; -- Variablen oder Kon- 

-- stanten Umbenennung 
package car renames komplexe_ari thmetik; 
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lm : float renames z(3,4); -- Umbenennung eines 

-- Matrixelementes 

function (x,y : complex) return complex 
renames komplexe_arithmetik.mult; 

-- Umbenennung der Funktion 
-- mult in das Zeichen * 


Hinweise: 

Umbenennungen dienen zur 

- Abkürzung 

- vorweggenommenen teilweisen Auswertung (etwa Auswahl einer 
Arraykomponente) 

- Auflösung von Namenskonflikten: Der Name einer Größe soll 
für andere Zwecke gebraucht werden, die Größe selbst soll 
jedoch sichtbar (zugänglich) bleiben. Der alte Name wird 
durch eine Umbenennung nicht verborgen. 

Die Umbenennung für einen Typ erfolgt durch eine Untertyp¬ 
vereinbarung (siehe 2.1.4). 
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3. AUSDRÜCKE 


Ein Ausdruck ist eine Formel zur Berechnung eines Wertes, 
wobei im wesentlichen die übliche mathematische Formel - 
Schreibweise verwendet wird. Ein Ausdruck besteht also aus 
Operanden (Variable, Konstante, usw.), Operatoren (+,-,*, 
and , usw.) und runden Klammern ( (x+5)*y ). Da die Berech¬ 
nung eines Ausdruckes einen Wert liefert, der von einem be¬ 
stimmten Typ x ist, müssen bei der Ausführung der einzelnen 
Operationen die Typen der Operanden und der jeweilige Opera¬ 
tor zusammenpassen. So hat es in der üblichen Bedeutung si¬ 
cherlich keinen Sinn, etwa den logischen Wert true und die 
ganze Zahl 5 zu addieren, also zu schreiben true + 5 . 
Trotzdem kann in ADA ein derartiger Ausdruck sinnvoll sein, 
dann nämlich, wenn der Operator + durch eine Operatorver- 
einbarung (siehe 3.9) eine zusätzliche Bedeutung bekommen 
hat. Man spricht dann von Überladung des Operatorzeichens, 
wobei sich die jeweilige Bedeutung aus den Operanden typen 
und dem Ergebnistyp ergibt. Wir klassifizieren in den folgen¬ 
den Abschnitten die Ausdrücke gemäß ihren Ergebnistypen, da 
beim Auftreten eines Ausdruckes im Programm dessen Ergebnis¬ 
typ das wesentliche Kennzeichen darstellt. So sprechen wir 
vom I AUSDRUCK, B AUSDRUCK usw., wenn der Ergebnistyp 
INTEGER, BOOLEAN usw. vorliegt. 

Unter Auswertung eines Ausdruckes versteht man 
die Bestimmung seines Wertes durch die Rechenanlage. 

Für die Auswertung eines Ausdruckes gelten folgende generel¬ 
le Regeln: 

- Die Operanden eines Operators (ausgenommen die Kurzschluß¬ 
formen and then und or eise , siehe 3.1) werden ausge¬ 
wertet. 

Dabei treten als Operanden auf: 
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- Variable (siehe 2.2) 

- Konstante (ADA 36 - 42,44,46,48) 

- Aggregate (ADA 43,45, 3.6, 3.7) 

- geklammerte Ausdrücke 

- Typkonversionen (siehe 3.10) 

- qualifizierte Ausdrücke 

- Funktionsaufrufe (siehe 5.4) 

- Generierungen von referierten Variablen (im Falle 
eines Zeigerausdruckes) (siehe 3.8) 

Bei einem qualifizierten Ausdruck wird durch den vorange¬ 
stellten Typnamen der Typ des Ausdruckes festgelegt. Die¬ 
se Qualifikation kann notwendig werden, wenn der Typ des 
Ausdruckes nicht eindeutig durch den Ausdruck selbst 
(Operanden und Operatoren) oder die Umgebung des Ausdruk- 
kes festgelegt ist. 

Die Operatoren werden gemäß der Klammerstruktur des Aus¬ 
druckes und der für die Operatoren festgelegten Rangfolge 
(größere Rangnummer vor kleinerer Rangnummer) ausgeführt: 


Rangnummer 

Operatoren 

1 

and, or, xor, and then, or eise 


Kuazs ckZuß & onmdYi 

2 

<, <=, >, >=, =, /=, J_n, not in 

3 

+ , -, & 

4 

+, -, not (einstellig) 

5 

*, /, mod, rem 

6 

** 


Dabei werden Operatoren mit gleicher Rangnummer als 
gleichrangig bezeichnet. 

Operatoren gleichen Ranges werden von links nach rechts 
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ausgeführt. 

- Ein geklammerter Ausdruck wird unabhängig von nebenstehen¬ 
den Operatoren ausgewertet. 

- Bei einigen Operatoren wird eine Ausnahmebehandlung bei 
bestimmten Operandenwerten ausgelöst. 

An einigen Stellen (z.B. 2.1.1.2) werden sog. stati¬ 
sche Ausdrücke gefordert. Diese müssen während 
der Übersetzung bereits ausgewertet werden. Deshalb dürfen 
in statischen Ausdrücken nur folgende Operanden auftreten 
(definitorisch): 

a) eine Literal Konstante oder ein Literal Ausdruck 

b) ein Aggregat mit statischen Ausdrücken 

c) eine Konstante, die durch einen statischen Ausdruck ini¬ 
tialisiert wurde 

d) die vordefinierte Funktion abs 

e) ein Attribut mit statischem Wert und attributierte Funk¬ 
tionsaufrufe mit statischen Ausdrücken als Operanden 

f) ein qualifizierter statischer Ausdruck oder eine Typkon¬ 
vertierung eines statischen Ausdruckes (mit statischen 
Einschränkungen) 

g) eine Komponente einer Record Konstante, die durch einen 
statischen Ausdruck initialisiert wurde 

h) eine indizierte Komponente einer Feld Konstante, die 
durch einen statischen Ausdruck initialisiert wurde, wo¬ 
bei die Indexausdrücke statisch sein müssen. 

Dabei sind als Operatoren zugelassen: 

a) alle vordefinierten Operatoren 

b) Mitgliedschaft (siehe 3.1) 

c) Kurzschlußformen (siehe 3.1) 

Die oben auftretende Literal Konstante be¬ 
zeichnet einen expliziten Wert eines gegebenen Typs (siehe 
ADA 36,37,38,39,40,42,46). 


3. Ausdrücke 
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In Literal Ausdrücken sind folgende Ope¬ 
randen möglich: 

- numerische Literal Konstanten 

- Namen von numerischen Literal Konstanten 

- Standardfunktionsaufruf von abs 

- ein geklammerter Literal Ausdruck. 

In einem Literal Ausdruck vom Typ universal_integer sind nur 
die vordefinierten Operatoren mit integer Operanden zulässig. 

In einem Literal Ausdruck vom Typ universal_real sind fol¬ 
gende Operatoren zulässig: 

- Vorzeichen +, -, die Funktion abs, die zweistelligen 

Operatoren für Operanden vom Typ universal_ 

real. 

- Multiplikation von uni versa l_real und uni versal_integer 
Operanden und umgekehrt. 

- Division und Exponentiation mit universal_real Operanden 
als ersten und universal_integer Operanden als zweiten 
Operand. 

Die Auswertung eines Literal Ausdruckes muß ein Ergebnis 
liefern, das mindestens so genau ist wie der genaueste zur 
Verfügung stehende numerische Typ. 

Hinweise: 

(1) Die Reihenfolge der Auswertung der Operanden eines Ope¬ 
rators ist nicht festgelegt. Es ist also darauf zu ach¬ 
ten, daß die Reihenfolge keinen Einfluß auf das Ergeb¬ 
nis des Operators hat. Dies könnte z.B. der Fall sein, 
wenn in einem Operanden ein Funktionsaufruf mit Neben¬ 
wirkung auf den anderen Operanden auftritt. 

(2) Wenn die Auswertung eines statischen Ausdruckes eine 
Ausnahmebehandlung erfordert, so wird der betreffende 
statische Ausdruck durch Code ersetzt, welcher diese 
Ausnahmebehandlung auslöst. 
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3.1 DER LOGISCHE AUSDRUCK (B AUSDRUCK) 

Logische Aussagen wie Vergleiche, die logischen Konstanten 
true und false ("wahr" und "falsch") können z.B. durch and 
und_or (logisches "und" und "oder") zu neuen logischen Aus¬ 
sagen verknüpft werden. Solche Gebilde werden hier logische 
Ausdrücke genannt. Dabei beschränken wir uns in diesem Ab¬ 
schnitt auf die Standardbedeutung aller auftretenden Opera¬ 
toren. (Andernfalls siehe 3.9). 

Die Auswertung eines logischen Ausdruckes bewirkt die Fest¬ 
stellung, ob die angegebene mathematisch logische Aussage 
den Wert true oder false hat. 

Syntax: 


ADA 28: BAUSDRUCK (B AUSDR. B A) 



PxioiüXät I 




























3.1 Logischer Ausdruck 


93 


ADA 29: B RELATION 

—|-B EINF AUS 

- B EINF AUS 

- CH EINF AUS 

-AZ EINF AUS 

- I EINF AUS 

—r— G EINF AUS 
•— F EINF AUS 

- A EINF AUS 

- ST EINF AUS 

- REC EINF AUS 

- Z EINF AUS 

- B EINF AUS 


- CH EINF AUS 


- AZ EINF AUS 


I EINF AUS 


- G EINF AUS 

- F EINF AUS 


ORDNUNGSRELATION 


(B REL) 



VzA.gieA.di 


UUgtiedidiajt 


(OREL) 


GLEICHHEITSRELATION (GREL) 
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B.3 Ausdrücke 


ADA 30: B EINFACHER AUSDRUCK (BEINF AUS) 



ADA 55: B E/A STANDARDFUNKTIONSAUFRUF 

f tAue, fallt InteAnet fite, mit exteAnem verbunden 
1 falte, tontt 

j tAue, fall i gegenteÖAtige Letepotition gxößeA alt 
| EndpotiXion lit 

[ falte, ioiti t 

f tAue, fallt die Zeltenlänge det inptU filet nicht 
■s gesetzt Ist bau. fallt de\ Weit de i aktuellen 

Komponente dat Zehenende Zeichen lit 
I falte, tontt 

Der attributierte Funktionsaufruf wird in Abschnitt 3.3 be¬ 
hände! t. 


Semantik: 


Die im Zusammenhang mit logischen Ausdrücken auftretenden 
Konstanten und Wortsymbole haben folgende Bedeutungen im 
mathematisch logischen Sinn: 


- C end of me V -to Fe{1F » I0F t TT . fJ . 
—(end_of_1ine MD- 


-CD— 


r ,TFA i 


Symbol 

Bedeutung 

true 

"wahr" 

• logische Konstanten 

false 

"falsch" 


not 

Negation 


and 

Konjunktion 


























































3.1 Logischer Ausdruck 
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Symbol 

Bedeutung 

or 

einschließlich^ Disjunktion 

xor 

ausschließliche Disjunktion 

and then 

1 

I 

or eise 

l 

L sog. Kurzschlußformen 


Die logischen Operatoren sind durch folgende Wertetabellen 
definiert: 


a 

ß 

not a 

a and ß 

a or ß 

true 

true 

false 

true 

true 

true 

false 

false 

false 

true 

false 

true 

true 

false 

true 

false 

false 

true 

false 

false 


a 

ß 

a xor ß 

a and then ß 

a or 

eise ß 

true 

true 

false 

true 


true 

"der Ope¬ 

true 

false 

true 

false 


true * 

rand ß wi rd 
nicht aus- 
,gewertet 

false 

true 

true 

false 

der Ope¬ 

true 


false 

false 

false 

false' 

rand ß wi rd 
nicht aus- 
.gewertet 

false 
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B.3 Ausdrücke 


Standardfunktionen 

Die Standardfunktionen (ADA 55) haben folgende Bedeutung: 
(a ist Wert für F AUSDRUCK, Fe$, 4>={IF,0F, IOF, ITF,0TF} 
ß ist Wert für T AUSDRUCK, T6[IF,IOF,ITF} 
y ist Wert für ITF AUSDRUCK ) 


Standard¬ 

funktion 

logischer 

Wert 

Bedeutungen und 
Bedingungen 

is_open(a) bzw. 
is_open(file=>a) 

true 

das interne File a ist mit 
einem externen File verbun¬ 
den 


false 

sonst 

e nd_of_file(ß) 

bzw. 

en d_of_f i1e(fi1e=>ß) 

true 

false 

die aktuelle Leseposition 
von ß ist größer als die 
Endposition 

sonst 

end_of_line(y) 

bzw. 

end of 1ine(file=>y) 

true 

die Zeilenlänge des input- 
Files ist nicht gesetzt bzw. 
der Wert der aktuellen Kom¬ 
ponente ist das Zeilenende¬ 
zeichen 


false 

sonst 


Ein Vergleich (ADA 29: B RELATION) ist eine logi¬ 
sche Aussage, die den Wert true hat, wenn der Operator die 
Anordnung der Operanden (die vom selben Typ sein müssen) in 
der durch ihren Typ bestimmten Ordnungsbeziehung beschreibt. 
Andernfalls hat der Vergleich den Wert false. 

Die Vergleichsoperatoren (ORDNUNGSRELA¬ 
TION) haben folgende Gültigkeit und Bedeutung: 









3.1 Logischer Ausdruck 
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Typ 

Verc 
<' 

leie 

<= 

:hsc 

> 

pera 

>= 

tor 

en 

Bemerkungen 

B 

< 


> 

> 

= 

4 

false < true 

CH 

< 


> 

>_ 

= 

4 

Ordnung gemäß ASCII-Zei¬ 
chensatz 

AZ 

< 

£ 

> 


= 

4 

Ordnung gemäß Reihenfolge 
in der Typdefinition 

I 

< 


> 

>_ 

= 

4 

natürliche Ordnung der gan¬ 
zen Zahlen 

G od. F 

< 


> 

> 

= 

4 



Das Modellintervall A eines reellen Wertes a ist das klein¬ 
ste Intervall mit Modell zahlen als Grenzen, das den reellen 
Wert enthält. 

Entsprechend dem Typ werden beiden Operanden a, b ihre Mo¬ 
del 1 interval le A, B zugeordnet und folgende Fälle unter¬ 
schieden: 

(a) A n B = 0 => Ergebnis entsprechend math. Definition 

(b) A = a, B = b, A = B => Ergebnis entsprechend math. De¬ 
finition 

(c) A n B = x (Modellzahl) => Ergebnis entsprechend math. 
Definition durch Vergleich der geg. Operanden a,b oder 
durch Vergleich des ersten Operanden mit sich selbst. 

(d) An B enthält mehr als einen reellen Wert => Ergebnis 
maschinenabhängig 

(e) Die Bildung von A oder B ergibt Überlauf => Ergebnis 
maschinenabhängig 


7 Kaucher IV - ADA 
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B.3 Ausdrücke 



Vergleichsoperatoren 


Typ 

ii 

A 

A 

II 

V 

V 

” 

/= 

Bemerkungen 


In diesem Fall kann, muß aber nicht, die Ausnahmebe¬ 
handlung numeric_error erfolgen. 


■ i 


I 

i 


* 

für nichtleere Felder glei¬ 
chen Typs komponentenweise 
erklärt, wobei die beiden 
Felder zueinander passen 
müssen, d.h. beginnend mit 
jeweils der unteren Grenze 
der Indexbereiche lassen 
sich aufeinanderfolgende 
Komponenten paarweise zuord¬ 
nen. Leere Felder vom sel¬ 
ben Typ sind immer gleich. 

A 

ei ndimen- 
sional 

< 

> 

> 

= 

t 

für diskreten Komponenten¬ 
typ erklärt, dabei wird le- 
xikographische Ordnung ge- 
prüft. Ein leerer Vektor 
ist kleinster Vektor. 

ST 

< < 

> 

> 

= 

4 

REC \ 

i 



t 


4 

für nichtleere Records glei¬ 
chen Typs komponentenweise 
erklärt, wobei die beiden 
Records zueinander passen 
müssen, d.h. beginnend bei 
der 1. Komponente paarweise 
gleiche Komponentennamen 
haben. Leere Records vom 
selben Typ sind immer gleich 

‘ \ 

k 

X 

X 

1 

4 

zwei Zeigerwerte sind 
gleich, wenn sie entweder 
beide auf dasselbe Objekt 
zeigen oder beide den Wert 
nul1 haben. 




1 
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-’ 

Typ 

Ter 

< 

gl ei 
<= 

chsop 

> > 

eratoi 

ren 

/= 

Bemerkungen 

geschütz¬ 
te Typen 
und struk 
turierte 
Typen mit 
geschütz¬ 
tem Typ 
als Kom¬ 
ponenten¬ 
typ 


1 

» 



nicht vergleichbar 


Typ 

Mitgliedschaft 
in 

not in 

B 

true, falls der Wert des linken Ope¬ 

false, ... 

CH 

randen innerhalb des rechtsstehenden 


AZ 

Bereichs liegt. Der Wert muß vom 


I 

gleichen Typ sein wie die Grenzen 


G 

des Bereichs bzw. wie der Grund¬ 


F 

typ des Untertyps. 



false, sonst 

true, sonst 


Beispiele: 

1. Seien a,b,c,d logische Variable mit den Werten a:= true, 
b:= true, c:= false, d:= false, so ergibt die Auswertung 
des logischen Ausdruckes 

(a xor b) or ( not a and (c or not d)) 

--v-' N -v- J 

false true 

'-v-' 

false 


7* 
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B.3 Ausdrücke 


den Wert false. 

2. Es seien x,y Variable vom Typ float_real. Dann gibt der 
logische Ausdruck (Vergleich von zwei logischen Aussagen) 

(y >= -x/8.5 + 1.5) = (y >= x/2.7) 

an, ob der durch das Paar (x,y) in der Zahlenebene be¬ 
schriebene Punkt gleichzeitig oberhalb der beiden Geraden 
y = -x/8.5 + 1.5, y = x/2.7 oder echt unterhalb dieser 
Geraden liegt. 

3. Sei p eine Zeigervariable auf einen Record Typ mit einer 
Komponente "daten". So erlaubt der Ausdruck 

p /= nul1 and then p.daten /= x 
das Durchsuchen einer entsprechenden Liste nach dem Wert 
x. 


3.2 DER ZEICHEN AUSDRUCK (CH AUSDRUCK) 

Zeichen sind Werte vom Typ Character. Dieser Ausdruck be¬ 
sitzt keine Standardoperatoren und keine Standardfunktionen. 

Syntax: 

ADA 28: CH AUSDRUCK (CH AUSDR, CH A) 



Der attributierte Funktionsaufruf wird in Abschnitt 3.3 be¬ 
handelt. 




























3.3 Ausdruck vom Aufzählungstyp 
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3.3 DER AUSDRUCK VOM AUFZÄHLUNGSTYP (AZ AUSDRUCK) 

Wie der Zeichen Ausdruck besitzt auch der Ausdruck vom Auf¬ 
zählungstyp weder Standardoperatoren noch Standardfunktio¬ 
nen. 

Syntax: 

ADA 28: AZ AUSDRUCK 



ADA 35: t ATTRIBUTlERTER FUNKTIONSAUFRUF (t ATTR FKT AUFRUF) r e e 0 u cg.f.stj 

O 0 • (ß.CH.AZ) 



Attributierte Funktionsaufrufe sind Aufrufe von typabhängi¬ 
gen Standardfunktionen, die jeweils mit dem entsprechenden 
Typnamen qualifiziert werden. 

Tritt das Attribut base auf, so wirkt der Aufruf auf den zu¬ 
grundeliegenden Basistyp. 
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B.3 Ausdrücke 


Beispiele: 

type ampel jis. (rot,rotgelb,gruen,gelb); 

type färbe j_s (blau,rot,gelb,weiss,grau,schwarz); 

subtype grauton J_s färbe ränge weiss .. schwarz; 

ampel'succ (rotgelb) hat den Wert gruen. 
grauton'value (weiss) hat den Wert 0. 
grauton'base'value (weiss) stimmt überein mit 
färbe'value (weiss) und hat den Wert 3. 
ampel' (rot) ist ein qualifizierter Ausdruck. 


3.4 DER GANZZAHLIGE AUSDRUCK (I AUSDRUCK) 


Der I AUSDRUCK hat folgenden syntaktischen Aufbau: 


ADA 28: 1 AUSDRUCK 



riÄoiUaLt 4 


P'UoiUäX 6 blext>0 
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3.4 Ganzzahliger Ausdruck 

ADA 31: I OPERAND (I OPD) 

0 - (B.CH.AZ.I.G.F.A.ST.REC.Z) 



ADA 35: 1 ATTRIBUTIERTER FUNKTIONSAUFRUF (I ATTR FKT AUFRUF) 

Oq • (B.CH.AZ.I) 

- I TYP NAME-0 


-1 TYP NAME -O- 


-A TYP NAME -0 



?)- ST AUSDR -0—I £ 


sücc)-l-0— I AUSDR —Q— 


We.it in 1 mit 
dei Position u 


VoigängeA 1 
Hachiotgei 


Lqüekd- 


-A VAR NAME-0- 

— A KONST NAME —Q- 


Cliiü 

jTTt)—I—— I AUSDR — (T )— 


± T, TYP NAME —0 
-A TYP NAME-0 

- A VAR NAME-0 

- A KONST NAME -0 

Seien v,y Operanden vom Typ integer. Dann gilt: 


Semantik: 



intomcA Weit 


J * 


cn irtdci 
btielchs 
vom Typ l 


- Die Operatoren +, haben die übliche mathematische Be¬ 
deutung. 
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B.3 Ausdrücke 


- Der Operator ** bedeutet Exponentiation. 

- Die ganzzahlige Division v/y, y + 0, und der Rest v rem y 
bei ganzzahliger Division haben als Ergebnis eine ganze 
Zahl. Sie sind definiert durch die Beziehung 

v=(v/y)*y+(v rem y) , 
wobei v rem y das Vorzeichen von v hat und 
abs(v rem y) < abs(y) ist. 

- Die modulo-Operation v mod y (Restklasse modulo y) ist 
definiert durch 

v = y * n + (v mod y) , n ganze Zahl, 
wobei v mod y das Vorzeichen von y hat und 
abs(v mod y) < abs(y) ist. 

Standardfunktionen: 

Sei v der Wert für einen I AUSDRUCK. 


Standard¬ 

funktion 

mathematische 

Bedeutung 

Bedeutung 

abs(v) 

|v| := vsign(v) 

Absolutbetrag von v, wobei 
die Vorzeichenfunktion 
sign durch 

f +1 v > 0 

sign(v): = < 0 für v = 0 

[ -1 v < 0 

definiert ist. 


Beispiele: 

i : integer := 2; 
j : integer := -3; 
k : integer := 5; 
l,m,n : integer; 

1:= i * j; 


1 erhält den Wert -6 zugewiesen 








3.5.1 Gleitpunktausdruck 
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m:= k/j; 
n:= k mod j; 
m:= k rem j; 


m erhält den Wert -1 zugewiesen 
n erhält den Wert -1 zugewiesen 
m erhält den Wert +2 zugewiesen 


Hinweise: 

(1) Bei den Operationen und ** erfolgt die Aus¬ 

nahmebehandlung numeric_error, wenn das Ergebnis außer¬ 
halb des Ergebnistyps liegt, insbesondere bei v/p, 

v _rem p, v mod p, falls p = 0 ist. 

(2) Für die ganzzahlige Division und die Operatoren rem und 
mod gelten folgende Eigenschaften: 

(-v/p) = -(v/p) = (v/-p) 
v rem (-p) = v rem p 
(-v) rem p = -(v rem p) 

v mod p = (v + k * p) mod p für alle ganzen Zahlen k 
v rem p = v mod p für sign(v) = sign(p) . 

(3) Bei negativem Exponenten bei der Exponentiation erfolgt 
die Ausnahmebehandlung constraint_error. 

3.5 DER REELLE AUSDRUCK 

Entsprechend den beiden reellen Typen, dem Gleitpunkt- und 
dem Festpunkttyp, gibt es auch zugehörige Ausdrücke. 


3.5.1 DER GLEITPUNKTAUSDRUCK (G AUSDRUCK) 


Der G AUSDRUCK hat folgenden syntaktischen Aufbau: 
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B.3 Ausdrücke 


ADA 28: G AUSDRUCK 


& 



. 




!••©•• 


!.. 0 " 

r.eeu* 

L- 1 - G OPD 

p^-©- I OPD -| 


P/UonUcU. 4 

ADA 31: G OPERAND (GOPD) 


- ZUN — G TYP NAME ■ 
■ ZUN — G TYP NAME - 


-©- 


■ ZUN - G TYP NAME -Q- 


-CD- 


- G VARIABLE - 

- G KONSTANTE - 

- G AUSDR- (j)- 

- G AUSDR-©- 

-1 AUSDR • 

- F AUSDR ■ 

-G AUSDR - 

- G AUSDR-(F>-| 


<D- 


- ZUN • 


- G ATTR FKT AUFRUF - 

-(HD— 

-G FKT NAME — AKT ARG LISTE ■ 




- G AUSDR - 




Semantik: 

- Die Gleitpunktoperatoren + , -, *, / haben die übliche 
mathematische Bedeutung, abgesehen davon, daß das Ergebnis 
im allgemeinen nicht Element des verwendeten Gleitpunkt¬ 
systems T sein wird. In diesem Falle gilt folgendes: 

Seien a,b e T vom gewählten Gleitpunkttyp und na,ob 6 M 
die entsprechenden Modell zahlen (wegen möglichem Basis¬ 
wechsel muß evtl, konvertiert werden). 

Oa bzw. Ob sei das kleinste a bzw. b enthaltende Mo¬ 
del lintervall (zugeordnetes Model 1intervall) 
(Nicht definiert, falls |a| > T'LARGE). 


Es gilt: 

A^a: = 
aeM 

A 


[a,a] , d.h. das Model 1intervall einer Model 1- 
zahl ist ein Punktintervall 
O A:= [va^Aa^] 


















































3.5.1 Gl eitpunktausdruck 
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v bzw. A bezeichne die monotone nach unten bzw. oben ge¬ 
richtete Rundung [35]. 

Zwei Elemente a,b e T werden derart miteinander verknüpft, 
daß gilt: 

(RG') A A ambe 0(0a<$>0b) , 

°6{+,-,*,/} a,beT 

wobei mit die der Verknüpfung <> entsprechende Inter¬ 
val 1 Verknüpfung bezeichnet sei. 

Intervalle schreiben wir in der Form 
[a,b] := (x eIR|aj<Xj<b} . 

Die Berechnung der Schranken der Gleitpunktverknüpfungen 
erfolgt also in 3 Schritten: 

1. Jedem Operanden wird ein Model 1interval1 zugeordnet. 

2. Diese Modellintervalle werden interval 1 arithmetisch 
verknüpft. 

3. Dem in Schritt 2. entstehenden Intervall wird ein Mo¬ 
dell intervall vom Ergebnistyp der zugrundeliegenden 
Operation zugeordnet. 

- Die Exponentiation a**n ist definiert als a n durch: 


a**n := 


a*a* ... *a, 

n 

> 0 

n-mal 



1 für 

n 

= 0 

l/(a*a* ... *a) 

n 

< 0 

-n-mal 




Beispiel: 

Der Gleitpunktausdruck 

((12192.0 * x - 32257.0) * x - 85344.0) * x + 225799.0 
hat für x = 2.645752 den Wert 3.0563905536e-8 . 
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B-3 Ausdrücke 


Hinweise: 

(1) Bei den Operationen +, -, *, / und ** erfolgt die Aus¬ 
nahmebehandlung numeric_error wenn das Ergebnis außer¬ 
halb des Ergebnistyps liegt. 

(2) Bei der Ausführung der Operationen kann bei Intervall- 
Überlauf die Ausnahmebehandlung numeric_error erfolgen 
(muß aber nicht). 

(3) Für zwei Modellzahlen a,b 0 M wird (RG 1 ) zu 

A A a El b e 0(3 • b) , 

t '6{+,-,*,/} a,b6M 

d.h. a El b liegt in einem Intervall, dessen Grenzen 
zwei benachbarte Modell zahlen sind. 

3.5.2 DER FESTPUNKTAUSDRUCK (F AUSDRUCK) 

Der F AUSDRUCK hat folgenden syntaktischen Aufbau: 

ADA 28: F AUSDRUCK 




F OPD 


PiUonltät 4 












3.5.2 Festpunktausdruck 
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ADA 31: F OPERAND (FOPD) 



Die Festpunktoperatoren + , -, * und / haben die übliche 
mathematische Bedeutung, wobei bez. Genauigkeit das für 
Gleitpunktoperationen Gesagte gilt. Die zulässigen Paare von 
I und F OPERANDen seien für * und / tabellarisch dargestellt 


Opera tor 

Operandentyp 
links rechts 

Ergebnis¬ 

typ 

Bemerkungen 

* 

F 

I 

wie links 

1 entspricht wieder- 
\ holter Addition und 


I 

F 

wie rechts 

J ist deshalb exakt. 


F 

F 

universel- 
1er Fest¬ 
punkttyp 

exakt, muß explizit 
in geeigneten Typ kon¬ 
vertiert werden. 

/ 

F 

I 

wie links 

i.a. nicht exakt 


F 

F 

universel¬ 
ler Fest¬ 
punkttyp 

das Ergebnis muß ex¬ 
plizit in geeigneten 
Typ konvertiert wer¬ 
den. 


Dabei können die auftretenden F OPERANDEN durchaus verschie¬ 
dene Festpunkttypen sein. 
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B.3 Ausdrücke 


Beispiel: 

Der Festpunktausdruck 

g*x**4-y**4 + 2*y**2 
hat für x = 10864.0 und y = 18817.0 den Wert 1. 


3.6 DER AUSDRUCK FÜR FELDER 


Für einige spezielle Felder sind vordefinierte Operatoren 
vorhanden, so daß sich damit Ausdrücke bilden lassen. Im 
allgemeinen muß jedoch der Benutzer eigene Operatoren ver¬ 
einbaren, etwa dann, wenn er Matrizen numerisch verknüpfen 
will (siehe 3.9). 

Der allgemeine A AUSDRUCK besteht demnach lediglich aus 
einer Aufzählung von Operanden (siehe ADA 31). Dabei tritt 
als Operand das sogenannte A AGGREGAT auf. Damit kann man 
den Wert eines Feldes angeben: 


Syntax: 


ADA A3: A AGGREGAT 

0 - {B,CH,AZ,I,G,F.A,ST,REC,Z) 0 Q » {B.CH.AZ, I} 



ausmhl 


Austestung de.fi Komponentenuieate 
in Reihenfolge 


mit Jndetangabe 


alten nesfliehen Komponenten 


Semantik: 

Ein Array Aggregat stellt einen Wert eines Feldes dar, in¬ 
dem alle Komponenten explizit (in Form von Ausdrücken) ange¬ 
geben werden. Dazu gibt es mehrere Möglichkeiten: 























3.6 Ausdruck für Felder 
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(a) Auflistung mit Indexangabe 

Ein Aggregat mit einer einzigen Komponente muß in dieser 
Form angegeben werden. 

Ist die KompomntznauAwakl ein einfacher Ausdruck, so 
ist dessen Wert der angesprochene Indexwert. 

Ist die Auswahl ein Indexbereich, so sind alle darin 
enthaltenen Indexwerte angesprochen. 

Allen durch eine Kompomn^nauMoahl gekennzeichneten 
Feldkomponenten wird der Wert des nach => stehenden Aus¬ 
druckes zugewiesen. Die Reihenfolge der Auflistung ist 
beiiebig. 

Die Indexgrenzen eines solchen Aggregates sind durch den 
kleinsten und größten auftretenden Indexwert gegeben. 

Der Wert jeder KomponzntznauAwakl muß statisch bestimm¬ 
bar sein, wenn das Aggregat mehr als einen Komponenten¬ 
wert enthält. 

Alle durch Kompomntencunivahl auftretenden Indexwerte 
müssen verschieden sein. 

Beispiel: 

Das Aggregat 

(1 .. 10 => 1 . 0,11 .. 20 => 0 . 0 ) 

stellt den Wert eines Vektors der Länge 20 dar. 

(b) Auflistung mit others 

Allen Komponenten wird der Wert des nach => stehenden 
Ausdruckes zugewiesen. Der Indexbereich ist durch den 
Kontext bestimmt. 

Derartige Aggregate dürfen nur in folgenden Zusammenhän¬ 
gen auftreten: 

1. Das Aggregat ist aktuelles Argument zu einem formalen 
Argument mit beschränktem Array Untertyp. 

2. Das Aggregat erscheint in einer return -Anweisung als 
der Ausdruck, der den Ergebniswert einer Funktion 
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angibt, deren Ergebnistyp ein A Untertyp mit be¬ 
schränktem Indexbereich ist. 

3. Das Aggregat ist entweder durch einen beschränkten 
Felduntertyp qualifiziert oder wird bei der Generie¬ 
rung einer referierten Variablen von einem A Unter¬ 
typ mit beschränktem Indexbereich verwendet. 

4. Das Aggregat tritt selbst innerhalb eines Aggregats 
auf, welches wiederum in 1., 2. oder 3. auftritt. 

In allen 4 Fällen sind die Indexgrenzen des Aggregats 
durch die im Kontext verfügbaren Indexangaben bestimmt. 

Beispiel: 

Das Aggregat 

( others => 0.0) 

weist allen Feldkomponenten den Wert 0 zu. 

(c) Auflistung in Reihenfolge 

Die Indexgrenzen des Aggregats sind wie in den in (b) 
beschriebenen Fällen 1. bis 4. ebenfalls durch die im 
Kontext verfügbaren Indexangaben bestimmt. Andernfalls 
ist die untere Grenze durch s'first bestimmt, wobei s 
der Index Untertyp ist. Die obere Grenze ist durch die 
Anzahl der Komponenten bestimmt. Diesen Feldelementen 
werden der Reihe nach die Werte der aufgelisteten Aus¬ 
drücke zugewiesen. 

Beispiel: 

Das Aggregat 
(0.1,0.5,1.2) 

gibt den Wert eines Vektors mit 3 Komponenten an. 

(d) Gemischte Auflistung 

In einem Aggregat darf die Auflistung mit Indexangabe 
und in Reihenfolge nicht gleichzeitig erfolgen. Die Auf¬ 
listung mit others bezieht sich im Zusammenhang mit (a) 
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bzw. (c) auf die restlichen Komponenten. 

Beispiel: 

Das Aggregat 

(1 .. 10 => 1.0, others => 0.0) 
gibt den Wert eines Vektors an, bei dem 10 Komponenten 
den Wert 1, alle anderen (vorstehenden bzw. nachfolgen¬ 
den ) den Wert 0 haben. 

(e) Ein Aggregat eines n-dimensionalen Feldes wird als ein¬ 
dimensionales Aggregat geschrieben, dessen Komponenten 
selbst wieder (n-l)-dimensionale Feldwerte sind. 

Beispiel: 

Das Aggregat 

(1 .. 10 => (1 .. 10 => 0 . 0 )) 
stellt den Wert einer 10*10-Matrix dar, deren Komponen¬ 
ten alle den Wert 0 haben. 

Hinweise: 

1. Die Reihenfolge der Auswertung der den einzelnen Komponen¬ 
ten zugeordneten Ausdrücken liegt nicht fest. Programme, 
die eine solche Reihenfolge voraussetzen, sind deshalb 
fehlerhaft. 

2. Aggregate können überladen werden, d.h. ein Aggregat kann 
sich in Abhängigkeit vom Kontext auf verschiedene Typen 
beziehen. 

3. Der einen Komponentenwert definierende Ausdruck muß die 
Beschränkungen der jeweiligen Komponente erfüllen. Andern¬ 
falls erfolgt die Ausnahmebehandlung constrained_error. 


8 Kaucher IV - ADA 
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3,6.1 DER AUSDRUCK FÜR FELDER MIT KOMPONENTEN- 
TYP boolean 

Wir bezeichnen im folgenden mit VB (VEKTOR BOOLEAN) einen 
eindimensionalen A Typ mit Komponententyp boolean. Die ent¬ 
sprechenden Syntaxvariablen sind also aus dem allgemeinen 
A Typ ableitbar. 

Syntax: 


VB AUSDRUCK (BOOLESCHER VEKTOR AUSDRUCK) 



VB EINF AUS 


1 

not 

. B OPD •: 


-B OPD —0-n 

-L_ VR OPD- 

•••• VB OPD •••©•■: 


V3 OPERAND 



Die logischen Operatoren not , and , or , xor werden komponenten- 
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weise ausgeführt. Dazu müssen die Operanden vom gleichen 
(nicht leeren) eindimensionalen A Typ mit Komponententyp 
boolean und gleicher Komponentenanzahl sein. 

Das Ergebnis ist vom selben VB Typ wie der (die) VB Operand 
(VB Operanden). 

Die Operation & (Konkatenation, Aneinanderhängen) fügt die 
beiden Operanden zu einem einzigen Vektor zusammen, in dem 
der linke Operand den vorderen und der rechte Operand den 
hinteren Teil bildet: 



Für einen eindimensionalen A Typ T mit dem Komponententyp C 
und dem Indexbereich 
index ränge <> 

wird die Wirkung der Operation & durch folgende drei Funk¬ 
tionen beschrieben: 

low : constant index := index'first; 

function (x,y : T) return T 

result : T(low .. index'val(index*pos(low) + (x'length + 


y'length - 1))); 


begin 


result(low .. index'val(index'pos(low)+(x'length-l))):=x; 
result(index'val(index 1 pos(1ow)+x'1ength) .. result'last) 


:= y; 


return result; 
end ; 

function (x : C; y : T) return T 
begin 

return (low => x) & y; 
end ; 


8* 
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function (x : T; y : C) return T 
begin 

return x & (low => y); 
end ; 

Hinweise: 

(1) Die Operanden der Operatoren and, or, xor brauchen nicht 
dieselben Indexgrenzen zu besitzen, aber sie müssen die 
gleiche Anzahl von Komponenten haben. Andernfalls er¬ 
folgt die Ausnahmebehandlung constraint_ error. 


3.6.2 DER AUSDRUCK FÜR EINDIMENSIONALE FELDER 


Wir bezeichnen im folgenden mit V (VEKTOR) einen eindimensio¬ 
nalen A Typ mit Komponententyp T. 

Syntax: 

V AUSDRUCK (VEKTOR AUSDRUCK) 


• r OPD 


—®~| 



•••• t OPD •: 

L v OPD — 

.... v OPD • 




V OPERAND 

analog VB OPERAND in 3.6.1 
Semantik: 


Analog 3.6.1. 
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3.6.3 DER AUSDRUCK FÜR ZEICHENKETTEN 
Syntax: 

ADA 28: ST AUSDRUCK 



•••• CH AUSDR •: 

—1— CH AUSDR —0-i 

1-1— ST OPD — 

•••• ST OPD 


ADA 31: ST OPERAND 


- ZUN - 

- ZUN - 


• ST TYP NAME - 

ST TYP NAME —Q- 


-<&- 


-ST AHR FKT AUFRUF- 

-ST E/A STANDARD FUNKTIONS AUFRUF - 
- ST FKT NAME — AKT ARG LISTE — 


- ST VARIABLE - 

- ST KONSTANTE ■ 

- ST AGGREGAT - 

- ST AUSDR - 

- ST AUSDR - 

-ST AUSDR- 

- ST AGGREGAT - 


•O" 


- ZUN-A FKT NAME — AKT ARG LISTE -©- 


-©- 

-©- 




- t. AUSDR 


Semantik: 




Die Konkatenation & hat die Bedeutung, wie in 3.6.1 be 
schrieben. 


Beispiel: 

"wer dauernd telefoniert"&"»bringt nichts zu papier. 
('a'j'd'.'a') ist ein Aggregat mit dem Wert "ada" . 


3.7 DER RECORD AUSDRUCK 


Kompontntznbjp ST 


Für Records sind standardmäßig keine Operatoren vorgesehen. 
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Der Record Ausdruck hat deshalb einen sehr einfachen Aufbau: 


Syntax: 

REC AUSDRUCK 
ADA 31: REC OPERAND 



ADA 45: REC AGGREGAT 

e - {B,CH,AZ,I,G,F,A,ST,REC,2) 



Au^ci fang dex Komponentenuexte 
in Reihenfolge 


mit Komponentenname 
atlex xeAtUchen 


Ein Record Aggregat stellt einen Wert eines Records dar, in¬ 
dem für jede Komponente (einschließlich Diskriminanten) ein 
expliziter Wert angegeben wird, unabhängig davon, ob eine 
Komponente bereits einen Wert besitzt oder nicht. Der Wert 
für eine Diskriminante muß durch einen statischen Ausdruck 
angegeben werden. Für die Angabe der Komponentenwerte gibt 
es folgende Möglichkeiten: 


(a) Auflistung mit Komponentenname 

Allen aufgelisteten, durch | getrennten Komponentennamen 
wird der Wert des nach => stehenden Ausdruckes zugewie¬ 
sen. Deshalb müssen alle diese Komponenten von demsel- 
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ben Typ sein. Die Reihenfolge der aufgelisteten Kompo¬ 
nentennamen ist beliebig. 

Beispiel: 
type complex is 

record real teil : real := 1.0; 

imaginaerteil : real := 0.0; 
end record ; 

Das Aggregat 

(realteil | imaginaerteil => 0.0) 
stellt den Wert eines Records mit 2 Komponenten dar, die 
beide den Wert 0 erhalten. 

(b) Auflistung mit others 

Wenn alle Komponenten denselben Typ haben und densel¬ 
ben Wert erhalten sollen, kann dies durch Auflistung mit 
others erreicht werden. 

Beispiel: 

Das Aggregat 

( others => 0.0) 

hat im Zusammenhang des Typs complex dieselbe Wirkung 
wie das Beispiel in (a). 

(c) Auflistung in Reihenfolge 

Den Re.cordkomponenten werden in der durch die Record¬ 
vereinbarung festgelegten Reihenfolge der Reihe nach die 
Werte der aufgelisteten Ausdrücke zugewiesen. 

Beispiel: 
type datum is 

record geburtstag,todestag : integer ränge 1 .. 31; 
geburtsmonat,Sterbemonat : monatsname; 
geburtsjahr,sterbejahr : integer ränge 


-5000 .. 3000; 
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end record ; 

Das Aggregat 

(12,7,Oktober,Oktober,1882,1942) 
stellt einen Wert des Recordtyps datum dar. 

(d) Gemischte Auflistung 

Dabei muß die Auflistung in Reihenfolge zuerst erfolgen 
Die Auflistung mit others bezieht sich im Zusammenhang 
mit (a) und (c) auf die restlichen noch verbleibenden 
Komponenten. 

Beispiel: 

Das Aggregat 

(12,7,geburtsjahr => 1882,Sterbejahr => 1942, 
others => Oktober) 

hat dieselbe Wirkung wie das Beispiel in (c). 

Hinweise: 

(1) Die Reihenfolge der Auswertung der den einzelnen Kompo¬ 
nenten zugeordneten Ausdrücken liegt nicht fest. Pro¬ 
gramme, die eine solche Reihenfolge voraussetzen, sind 
deshalb fehlerhaft. 

(2) Aggregate können überladen werden, d.h. ein Aggregat 
kann sich in Abhängigkeit vom Kontext auf verschiedene 
Typen beziehen. 

(3) Der einen Komponentenwert definierende Ausdruck muß die 
Beschränkungen der jeweiligen Komponente erfüllen. An¬ 
dernfalls erfolgt die Ausnahmebehandlung constraint_- 
error. 

(4) Bei Auflistung in Reihenfolge müssen die Werte für Dis- 
kriminanten zuerst angegeben werden, da der Diskriminan 
tenteil zuerst angegeben wird. Zudem müssen die Diskri- 
minantenwerte in derselben Reihenfolge wie im Diskrimi¬ 
nantenteil angegeben werden. 







3.8 Ausdruck für Zeiger 
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3.3 DER AUSDRUCK FÜR ZEIGER 

Für Zeiger sind standardmäßig keine Operatoren vorgesehen. 
Der Zeiger Ausdruck hat deshalb einen sehr einfachen Aufbau 


Syntax: 

Z AUSDRUCK 
ADA 31: Z OPERAND 



Die Ausführung der Speicherbelegungsfunktion new erzeugt ein 
Objekt vom referierten Typ und liefert als Wert einen Zeiger 
auf dieses Objekt. Vor der Objekterzeugung wird zunächst je¬ 
der Ausdruck, jedes Aggregat, jede Diskriminantenfestlegung, 
jede Indexbereichseinschränkung ausgewertet. Dann wird ein 
neues Objekt vom referierten Typ erzeugt. Ist der referierte 
Typ ein A Typ mit unbeschränktem Indexbereich oder ein REC 
Typ mit Diskriminanten ohne Diskriminantenfestlegung, so muß 
die Speicherbelegungsfunktion entweder einen expliziten An¬ 
fangswert (ein Ausdruck oder ein Aggregat) enthalten, oder 
einen Index oder eine Diskriminantenfestlegung. Dies ist der 
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einzige Fall, in dem ein Index oder eine Diskriminantenfest¬ 
legung erlaubt ist. Das erzeugte Objekt ist eingeschränkt 
entweder durch eine explizite Einschränkung oder durch die 
Schranken oder Diskriminanten der Anfangswerte. 

Falls der referierte Typ oder einige seiner Komponenten vor¬ 
definierte Anfangswerte besitzen, werden diese Initialisie¬ 
rungen ausgeführt. Zum Schluß werden die explizit angegebenen 
Anfangswerte zugewiesen, wobei die Einschränkungen des refe¬ 
rierten Typs zu beachten sind, und ein Zeigerwert, der auf 
das erzeugte Objekt zeigt, wird bereitgestellt. Das hiermit 
erzeugte Objekt bleibt solange erhalten, wie man potentiell 
darauf zugreifen kann. Andernfalls kann (aber muß nicht) der 
belegte Speicherplatz frei gegeben werden (maschinenabhängig). 

Beispiel: 

Mit den Vereinbarungen 
type zeiger; 

type element record daten : integer; 

nachfolger : zeiger; 
end record ; 

type zeiger i_s access element; 
p : zeiger; 

wird durch die Wertzuweisung 
p := new (element(10,p)); 

an die bestehende Liste mit Anfangsverweis p ein neues Ele¬ 
ment vorangestellt. Dieses Element ist mit dem Aggregat 
(10,p) initialisiert. 

Hinweise: 

(1) Wenn bei der Ausführung von new gegebene Einschränkungen 
unverträglich sind, erfolgt die Ausnahmebehandlung 
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constraint_error 

(2) Wenn bei der Ausführung von new nicht genügend Speicher¬ 
platz für das zu erzeugende Objekt vorhanden ist, erfolgt 
die Ausnahmebehandlung storage_error. 

(3) Wenn eine bestimmte Anwendung eine stärkere Kontrolle 
über die Speicherplatzbelegung bei Zeiger-Typen erforder¬ 
lich macht, sind folgende Maßnahmen möglich: 

(a) Der gesamte Speicherplatzbedarf von Objekten eines 
Zeiger Typs kann durch eine Längenangabe festgelegt 
werden (siehe 8.2.1). 

(b) Mit der Direktive controlled (siehe 8.1) kann die au¬ 
tomatische Speicherplatzrückgabe auf den Fall be¬ 
schränkt werden, daß der Gültigkeitsbereich der Zei¬ 
gertypvereinbarung verlassen wird. 

(c) Mit Hilfe des vordefinierten Programmschemas un- 
checked_deallocation kann der Speicherplatz einzel¬ 
ner Objekte vom referierten Typ frei gegeben werden 
(siehe 8.3). 


3,9 DAS ÜBERLADEN VON OPERATOREN 

Wir haben bisher die logischen Operatoren and, o^, xor , die 
Vergleichsoperatoren <, <=, >, >=, die Additionsoperatoren + , 
-, &, die einstelligen Operatoren +, -, not , die Multiplika¬ 
tionsoperatoren *, /, mod , rem und die Exponentiation ** in 
ihrer Standardbedeutung kennengelernt. Genau diese Operatoren 
können mittels einer FunktionsVereinbarung überladen werden, 
d.h. der entsprechende Operator kann beliebig vereinbarte 
Operandentypen zu einem beliebig vereinbarten Ergebnistyp 
verknüpfen. Die genaue Vorgehensweise wird in Abschnitt 5.7 
ausführlich behandelt. 
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Syntax: 


Aus 

ADA 7: UNTERPROGRAMM SPEZIFIKATION (UPG SPEZIF) 
Tj ,Tj 6 e u t 


w- - TYP — 0- return — T f TYP - 

-(ED - (TW T, VAR NAME -Q- T, VAR NAME - 


P/UoxUÄC 3 < —— 

UüD- 


r, VAR NAME —Q- 


C 7 U, 


I.© 

l r60 “'- i VAR NAHE -Q 


-©" — ■©■ 
O-RT-O- 
-O- A2I -©- 

-GD — 
-SD— 
-O— 


HZE> 

-CD— 

-CZD— 


-0- !5ä 0- 

-0- £ü 0- 

-S)— 


■°C1„ 
T“L 

L in -1— r 


, TYP 


0- return - ß TYP - 


0-|- r, VAR NAME -0- t, VAR NAME -0- 


m. 


, TYP 


.O. 

r VAR NAME -0 


ÜTU 


0- return - T ? TYP- 


Seman tik: 


genau 1 Vaxiablt 


Von den beiden Argumenten der Operatorvereinbarung ent¬ 
spricht das erste dem linken, das zweite dem rechten Operan¬ 
den des Operators. 

Der Operator "=" kann nur für limitierte geschützte Typen 
überladen werden. Mit dem überladen von "=" ist implizit 
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auch "/=" überladen. 

Haben ein lokaler und ein globaler Operator die gleichen Ar¬ 
gument - und Ergebnistypen, so ist der lokale Operator gül¬ 
tig. 

Hinweise: 

(1) Der Operator "/=" darf nicht explizit überladen werden. 

(2) Man beachte, daß das überladen von Operatoren die 
Priorität nicht verändert. 


3.10 DIE TYPKONVERTIERUNG 

Mit Hilfe der Typkonvertierung kann man sich den strengen 
Typregeln, z.B. in Ausdrücken, bequem anpassen. Dabei erhöht 
der Zwang zu expliziten Typanpassungen die Durchsichtigkeit 
der durchgeführten Operationen. 

Syntax: 

Aus 


ADA 31: t OPERAND 


— ZUN • 


■ r, TYP NAME 


• t 2 AUSDR ■ 


Es sind folgende drei Fälle erlaubt: 

(a) Konvertierung zwischen numerischen Typen: 

Seien Tj und T^ beliebige numerische Typen. Dann wird 
der Wert des T^ Ausdruckes in den Basistyp von Tj umge¬ 
wandelt. Bei real Typen liegt das Ergebnis innerhalb der 
vereinbarten Genauigkeit. Die Konvertierung von real 
nach integer erfordert i.a. eine Rundung. 
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(b) Konvertierung zwischen Feld Typen: 

Seien und A TYPen. Die Konvertierung ist zulässig, 
wenn die Basistypen der Indexbereiche für jede Dimension 
gleich oder voneinander abgeleitete Typen sind und wenn 
die Komponententypen gleich oder voneinander abgeleitete 
Typen sind. Ist Tj ein unbeschränkter A Typ, so sind die 
Grenzen des Ergebnisses die von T^. Ist T ? ein beschränk¬ 
ter A Typ, so müssen beide Typen zueinander passen. Die 
Grenzen des Ergebnisses sind die von T ? und die Kompo¬ 
nenten des Ergebnisses stimmen mit denen des Operanden 
überein. 

(c) Konvertierung zwischen Basistyp und abgeleiteten Typen: 
Die Konvertierung ist zulässig, wenn T ? von bzw. 

von Tj direkt abgeleitet ist. Diese Konvertierung kann 
Darstellungswechsel bewirken (siehe 8.2). 


Beispiele: 

zu (a): Die Konvertierung 
integer(13.4) 

konvertiert die Zahl 13.4 nach 13 oder 14 (maschi¬ 
nenabhängig). 

zu (b): type real jjs new float ränge 0 .. 30; 
type a j_s array (1 .. 10) of float; 
type b array (19 .. 40) of real; 
x : a; 

Die Konvertierung 
b(x) 

konvertiert das Feld x in den Typ b mit den Index¬ 
grenzen 19 .. 28 . (Basistyp ist hier integer). 
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Hinweise: 

(1) Eine Typkonvertierung bewirkt die Ausnahmebehandlung 
constraint_error falls der Wert des Operanden einer Be¬ 
schränkung des Ergebnistyps nicht genügt. Bei Typen be¬ 
zieht sich das auch auf alle Indexfestlegungen. 


3,11 ATTRIBUTE 

Attribute bezeichnen bestimmte vordefinierte Eigenschaften 
von Größen. Dabei kann ein Attribut einen Wert, eine Funk¬ 
tion oder einen Typ oder Untertyp darstellen. Ein Attribut 
wird mit dem Namen der Größe, einem nachfolgenden Hochkomma 
und dem abschließenden Attributnamen (evtl, mit Argument¬ 
liste) bezeichnet. 

In dieser Form treten sie auf in ADA 22: T TYP, in ADA 62: 

T ATTRIBUTIERTER FUNKTIONSNAME, in ADA 35: T ATTRIBUTIERTER 
FUNTIONSAUFRUF und in ADA 36 bis ADA 40: T KONSTANTE, 
bzw. in den Abschnitten 3.1 bis 3.5 und 9.8 . 
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A. ANWEISUNGEN 


In diesem Abschnitt werden einige einfache Anweisungen einge¬ 
führt. Diese sind im A moAAimgbtoJJL einer Programmeinheit 
beliebig verwendbar, wobei natürlich nur die sinnvolle An¬ 
ordnung auch einen sinnvollen Programmablauf ergibt. Syntak¬ 
tisch ist keine Reihenfolge festgelegt, jedoch ist die Be¬ 
deutung (Semantik) des Programmes von den verwendeten Anwei¬ 
sungen und deren Reihenfolge abhängig. Daher muß das zu be¬ 
arbeitende Problem zuvor, wie in A.3 beschrieben, so aufbe¬ 
reitet werden, daß die Reihenfolge der zu programmierenden 
Anweisungen daraus hervorgeht. 

In ADA wird jede Anweisung durch ein Semikolon abgeschlossen, 
während z.B. in PASCAL das Semikolon zwei Anweisungen trennt. 
An jeder Stelle, wo eine Anweisung stehen darf, darf auch 
eine Folge von Anweisungen stehen. 

Folgende Anweisungen werden hier näher behandelt: 

Aus ADA 23: ANWEISUNG (ANW) und ADA 2A: STRUKTURIERTE ANWEISUNG 
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Außerdem werden einfache Ein- bzw. Ausgabeanweisungen behan¬ 
delt. 

Die Anweisungen zum Aufruf von Unterprogrammen, zum Auslösen 
einer Ausnahme oder zur Synchronisierung von Prozessen wer¬ 
den in den entsprechenden Kapiteln besprochen. 


4,1 DIE LEERE ANWEISUNG 

Die e Anwe^Uung hat keine Wirkung. Sie kann benützt wer¬ 
den, wenn syntaktisch eine Anweisung gefordert wird, aber 
vom Programmierer keine Wirkung bei der Ausführung des Pro¬ 
grammes beabsichtigt ist. 

Syntax: 

Aus 


ADA 23: ANWEISUNG (ANW) 


O 


9 Kaucher IV - ADA 
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Semantik: 

Die leere Anweisung hat keine Wirkung. Sie kann wie jede an¬ 
dere Anweisung mit einer Marke versehen werden und als 
Sprungziel dienen. 


4.2 DIE WERTZUWEISUNG 

Eine Wertzuweisung dient dazu, einer Variable (d.h. deren 
Speicherbereich) einen Wert zuzuordnen. Der bisherige Wert 
der Variable wird durch den neuen Wert überschrieben und 
geht damit verloren. Ab diesem Zeitpunkt trägt die Variable 
den neuen Wert. 

Syntax: 

Aus 

ADA 23: ANWEISUNG (ANW) 

UVUZUUKÄAWQ 

—^- T VAR —©— T AUSDR-0- 


Semantik: 

Eine Wertzuweisung bewirkt die Auswertung des rechts stehen¬ 
den T AUSDRUCKes mit dem Ergebnistyp w und die Auswertung 
der links stehenden Variablen. Diese Auswertung kann paral¬ 
lel erfolgen. Kommt es jedoch bei Arrayzuweisungen zu Über¬ 
lappungen, so werden zuerst die rechts stehenden Komponen¬ 
ten ausgewertet. 

Dann erfolgt die Zuweisung von w an die links stehende Vari¬ 
able, falls ü) alle für die links stehende Variable gelten¬ 
den Einschränkungen erfüllt. 

Bei Arrayzuweisungen muß die Anzahl der Komponenten und der 
Komponententyp übereinstimmen. 
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Hinweise: 

(1) Das Zuweisungszeichen := ist ein Zeichen, obwohl auf 
Eingabetastaturen in der Regel die beiden Tasten für : 
und = gedrückt werden müssen. Diese müssen jedoch unmit¬ 
telbar aufeinanderfolgen. Zum Beispiel ist die Zeichen¬ 
folge : u = kein Zuweisungszeichen. 

(2) Der Wert u ist bestimmt, wenn alle im rechts stehenden 
Ausdruck auftretende Größen einen bestimmten Wert haben 
(sonst unbestimmt). Nach Ausführung der Wertzuweisung 
hat dann die links stehende Variable ebenfalls einen be¬ 
stimmten (sonst unbestimmten) Wert. 

(3) Das Zuweisungszeichen := darf keineswegs mit dem Gleich¬ 
heitszeichen = einer mathematischen Gleichung verwech¬ 
selt werden. So ist die Wertzuweisung 

i := i+1 

durchaus sinnvoll (der Wert von i wird um 1 erhöht), 
während die Gleichung 

i = i+1 

mathematisch falsch ist. 

(4) Ist der referierte Typ einer Zeigervariable ein Record 
Typ mit Diskriminanten, so können die Diskriminanten 
durch eine Wertzuweisung nicht verändert werden, da ja 
bei der Zeigertypvereinbarung der referierte Typ durch 
eine aktuelle Diskriminantenliste festgelegt wurde. 


4.3 EINFACHE ANWEISUNGEN FÜR EIN- UND AUSGABE 

Die Wertzuweisung als Mittel, einer Variable einen Anfangs¬ 
wert zuzuordnen, ist i.a. nicht flexibel genug. So läßt es 
sich beispielsweise mit der Wertzuweisung alleine ohne un- 


9* 
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sinnigen Schreibaufwand nicht realisieren, ein und dasselbe 
Programm mit verschiedenen Datensätzen zu rechnen. Dazu be¬ 
nötigt man eine Eingabeanweisung. 

Andererseits genügt es uns nicht, wenn nach Beendigung des 
Programmes irgendwelche Variable des Programmes das Ergebnis 
enthalten, sondern wir wollen das Ergebnis auch sehen, z.B. 
auf Papier gedruckt oder am Bildschirm. Dazu benötigt man 
eine Ausgabeanweisung. 

In der Regel erfordert jedes ADA-Programm ein auf die ver¬ 
wendeten speziellen Typen zugeschneidertes Ein-/Ausgabe-Pa- 
ket. Zur Erstellung solcher Pakete stehen die Standardpakete 
low_level_io, input_output und text_io zur Verfügung. Das 
Paket low_level_io beschreibt Möglichkeiten, mit einem phy¬ 
sikalischen Peripheriegerät direkt von einem ADA-Programm 
aus zu kommunizieren. Das Paketschema input_output be¬ 
schreibt die Handhabung von Dateien (Files) mit Komponenten 
eines Typs und die Ein- und Ausgabe auf solche Files. Wäh¬ 
rend hier die Daten in interner Form auf die Datei abgespei¬ 
chert werden, beschreibt das Paket text_io die Handhabung 
von Textfiles. Das sind Dateien, auf denen Komponenten ver¬ 
schiedener Typen in lesbarer Form abgespeichert werden. Die 
Standardein- und ausgabe etwa von einem Bildschirmgerät aus 
wird stets mit solchen Files arbeiten. Im Paket text_io fin¬ 
den sicff Pakete bzw. Paketschemata für die Ein- und Ausgabe 
aller skalaren Typen und für Strings. Ausprägungen der Sche¬ 
mata für die Standardtypen integer und float haben wir in 
dem Paket Standard_EA zusammengefaßt. 

with text_io; use text_io; 
package Standard_EA is 

package int_io j_s new integer_io (integer); 
package flo_io is new float__io (float); 
use int_io; float_io; 
end package Standard_EA; 
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Das Paket Standard_EA stellt alle Ein/Ausgabeunterprogramme 
des Pakets text_io zur Verfügung, also speziell die Verein¬ 
barung von Textfiles, die Ein/Ausgabe für character, string 
und boolean sowie Funktionen und Prozeduren zur Gestaltung 
des Druckbilds. 

Außerdem werden durch Erzeugung der Pakete int_io und float 
_io Ein/Ausgaberoutinen für die Standardtypen integer und 
float bereitgestellt. 

Wird also das Paket Standard_EA mittels einer Kontextangabe 
zu einer Programmeinheit gebunden, so kann in dieser Pro¬ 
grammeinheit Ein- und Ausgabe von Standardtypen erfolgen. 

Die einfachsten und wichtigsten der Unterprogramme stellen 
wir hier vor. Eine genaue Beschreibung der gesamten Ein/Aus¬ 
gabe und Filehandhabung erfolgt in Kapitel 11. 

Syntax: 

Aus 

ADA 54: E/A PROZEDURAUFRUF 

6 0 • (B.CH.AZ.I) 
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Als Kommentare stehen die Namen der formalen Argumente. 
Semantik: 

Es gelten folgende Vorbesetzungen der Argumente: 
file = Standard input bei get 
= Standard output bei put 
width = 0 
lower_case = false 
base = 10 

manissa = float'digits 
exponent = 2 

Bei get wird eine Konstante des angegebenen Typs vom Einga¬ 
befile gelesen und mittels der attributierten Funktion value 
der angegebenen Variable zugewiesen. Man beachte, daß die 
eingelesene Variable ein Ausgabeargument von get ist. 

(Hier besteht die Gefahr einer Verwirrung: Der Begriff Aus¬ 
gabeargument (Ausgangsargument) bezieht sich auf die Über¬ 
gabeart des Arguments der Prozedur get. Die Prozedur get be¬ 
sorgt die Eingabe (das Einlesen) von Werten.) 

put schreibt den Wert des Ausdrucks, der mit Hilfe der at¬ 
tributierten Funktion image in lesbare Form gebracht wird, 
auf das Ausgabefile. Dieser Ausdruck ist ein Eingabeargument 
der Prozedur, d.h. es erfolgt ein Wertaufruf, es darf also 
ein Ausdruck angegeben werden. Für character wird ein Zei¬ 
chen geschrieben, für strings so viele, wie der Stringlänge 
entsprechen. Für boolean, integer oder float werden width 
Zeichen geschrieben, jedoch mindestens so viele, wie zur 
Darstellung des Wertes nötig sind. Boolean werden linksbün¬ 
dig geschrieben, falls lower_case = true ist in Kleinbuch¬ 
staben, sonst in Großbuchstaben. Integer werden rechtsbündig 
geschrieben, die Darstellung gilt zur Basis base. Gleit¬ 
punktzahlen werden rechtbündig geschrieben mit 
Mantissenziffern und dx.ponznt Exponentziffern. WcmtLbba. 
sollte nicht größer als float'digits sein, da nur so viele 
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Ziffern relevant sind. 

Syntax: 

Aus 


ADA 53: FILEVERWALTUNGSPROZEDURAUFRUF 



Textfiles sind zeilenorientiert. 

new_line beendet die Ausgabe einer Zeile auf das Ausgabefile 
(Standard output) und gibt n-1 Leerzeilen aus (Vorbesetzung 
n = 1). 

skip_line beendet die Eingabe einer Zeile vom Eingabefile 
(Vorbesetzung: Standard input) und überliest n-1 weitere 
Zeilen (Vorbesetzung n = 1). 

Syntax: 

Aus 


ADA 55: B E/A STANDARDFUNKTIONSAUFRUF 


~d 


end of file 


end of line 



ITF A 
ITF A 



Semantik: 

Das Ergebnis eines Aufrufs ist true, falls das Ende des Ein¬ 
gabefiles bzw. das Ende einer Zeile des Eingabefiles (Stan¬ 
dard input) erreicht ist, sonst false. 
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Beispiel: 

Auf der Eingabedatei seien die folgenden Konstanten die 
nächsten zu lesenden Werte: 

13 37.4 

Durch die Anweisungen 

get(i); 
get(x); 
put(i,5,2); 
new_line; 
put(i); 
put(x,12,4); 

erhalten die Variablen i und x die Werte 13 und 37.4 (evtl, 
durch Konvertierung verfälscht) und es werden folgende Zei¬ 
chenfolgen gedruckt: 

c.1101 

13u«u3.740e+01 

Hr *- y-s 

notwendige angegebene Stellen- 
Stellenzahl zahl = 12 

Hinweis: 

Wir werden bis zum Kapitel 11 die Ein/Ausgabeprozeduren nur 
für die Standard-Ein-Ausgabedateien benutzen. 

Man beachte, daß end_of_file stets ein Argument benötigt, 
während end_of_line ohne Argument aufrufbar ist. 

Alle angegebenen Prozeduren und Funktionen sind in der Weise 
überladen, daß es auch möglich ist, das 1. Argument (das 
File) wegzulassen. Tatsächlich existieren z.B. für den Typ 
integer 2 verschiedene put Prozeduren, eine mit Angabe des 
Files, die andere ohne. Die Fortiassung der Formatangabe 
uoldtk oder der Basisangabe bo6e erfolgt dagegen nach den in 
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ADA üblichen Aufrufregeln für Argumente mit vorbesetztem An 
fangswert (vgl. Kap. 5). 


4.4 DIE BEDINGTE ANWEISUNG 

Soll ein Programm nicht nur stur einen einzigen möglichen 
linearen Ablauf haben, so bedarf es sogenannter V e r - 
zwei g u n g e n . Eine Verzweigung kann auf mehrere Ar¬ 
ten erreicht werden. Wir besprechen hier die bedingte Anwei 
sung, welche eine solche Verzweigung in Abhängigkeit vom lo 
gischen Aussagewert von logischen Ausdrücken ermöglicht. 

Syntax: 

Aus 

ADA 24: STRUKTURIERTE ANWEISUNG 

bedingte ArtweiMing 







j_f - 

- B AUSDR — then J 

L ANW - 

j- eise -1 

1- ANW n : 


-r eise 

I-L end — 1f • 


Semantik: 

Die bedingte Anweisung 

j_f ß-, then a, elsif ß 0 then a 0 ... elsif ß then a 
j. i c - - n - n 

^ a n+l 

end if 

mit den logischen Ausdrücken ß 1# ...,ß und den Anweisungs¬ 
folgen a 1 ,...,a n+1 ermöglicht die Auswahl einer Anweisungs¬ 
folge a.j in Abhängigkeit von den logischen Ausdrücken ß.. 

Es werden nacheinander die logischen Ausdrücke ß^ß^,... 
ausgewertet. Sobald sich für ein ß^ der Wert true ergibt, 
wird die Anweisungsfolge « k ausgeführt und die Ausführung 
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der bedingten Anweisung ist beendet; sind alle ß. false, 
wird a n+ i ausgeführt und die Ausführung der Anweisung been¬ 
det. 

Beispiel: 

rf abso <= 0.01 then gut:= gut + 1; 

elsif abso <= 0.05 then brauchbare brauchbar + 1; 

elsif abso <= 0.2 then schlechte schlecht + 1; 


eise unbrauchbare unbrauchbar + 1 


Hinweise: 

Fehlen die mit elsif eingeleiteten Alternativen, so liegt 
die aus PASCAL bekannte bedingte Anweisung vor mit folgenden 
Ausnahmen: 

Die einzelnen Alternativen sind Anweisungsfolgen. 

Die bedingte Anweisung wird durch end if abgeschlossen. 

4,5 DIE WIEDERHOLUNGSANWEISUNG UND DER SPRUNG 
AUS DER SCHLEIFE 

Die Wiederholungsanweisung dient dazu, eine Folge von Anwei¬ 
sungen solange zu wiederholen, bis eine Bedingung erfüllt 
ist oder eine feste Anzahl von Wiederholungen erreicht ist. 

Syntax: 

Aus 

ADA 24: STRUKTURIERTE ANWEISUNG 



ITER KLAUSEL 


I 



ADA 25: ITERATIONSKLAUSEL (ITER KLAUSEL) 
0 0 » {B.CH.AZ.I) 


for — t VAR NAME — in 


— j— reverse —| 


reverse 


Schte-iienindex 

while - ß AUSDR — 


T INDEX BER 


1 


Klau* eJL 
«rfu£e- 


Bedingung 
























4.5 Wiederholungsanweisung, Sprung aus Schleife 


139 


Semantik: 

Ohne die Iterationsklausel wird die Anweisungsfolge solange 
ausgeführt, bis eine exit , return , goto Anweisung aus dieser 
Folge herausführt, eine Ausnahme auftritt oder die Ausfüh¬ 
rung durch eine Terminierungsanweisung abgebrochen wird. 

Im Fall einer whij_e-Klausel wird die Bedingung vor jedem 
Schleifendurchlauf qeprüft und die Schleife nur durchlaufen, 
falls die Bedingung den Wert true hat. 

Im Fall einer for-Klausel wird zuerst der Schleifenindex als 
lokale Variable eingeführt. Falls der Indexbereich leer ist, 
wird die Anweisungsfolge nicht durchlaufen. Sonst wird sie 
für jeden Wert des Indexbereiches einmal durchlaufen. Vor 
jedem Durchlauf wird der Wert an den Schleifenindex in auf¬ 
steigender (bei reverse in absteigender) Reihenfolge zuge¬ 
wiesen. Der Schleifenindex ist innerhalb der Anweisungsfolge 
eine Konstante, darf also nicht durch Wertzuweisungen oder 
Argumentübergabe vom Modus out oder in out verändert werden. 

Der Schleifenname muß am Schluß erscheinen, falls er am An¬ 
fang steht. 


Der Sprung aus Schleifen: 

Die exit- Anweisung ist eine Anweisung zum Verlassen einer 
Schleife. 

Syntax: 

Aus ADA 23: ANWEISUNG 


[ 1 


ZUN • 


■ SCHL NAME — 


• B AUSDR 


1 


<D- 












140 


B.4 Anweisungen 


Semantik: 

Ist ein Schleifenname angegeben, so wird die benannte Schlei 
Schleife, sonst die innere Schleife verlassen. Falls eine 
Bedingung angegeben ist, wird die Schleife nur verlassen, 
falls die Bedingung erfüllt ist. 

Eine exi_t-Anweisung darf nur innerhalb einer Wiederholungs¬ 
anweisung stehen. 

Die Nachfolgeanweisung darf nicht außerhalb des Rumpfes ste¬ 
hen, der die Schleife enthält. Gegebenenfalls ist hier eine 
leere Anweisung einzufügen. 

Beispiele: 

1. loop 

get(x); absoeabs(x-s); 
if abso <= 0.01 
then gut:= gut + 1; 
e lsif abso <= 0.05 
then brauchbare brauchbar + 1; 
elsif abso <= 0.2 
then schlechte schlecht + 1; 
eise unbrauchbare unbrauchbar + 1; 
end if ; 
ie i + 1; 
exit when i = n; 
end loop ; 

2. while i = 324 
loop 

se s + (offset + faks); 
te t + (offset + fakt); 
fakse faks/2.0; 
fakte fakt * 2.0; 
ie i + 1; 
end loop ; 
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3. for i jm 1 .. n 
loop 

get(x); 
xx:= x; 
qs:= 0; 
while x < 0 
loop 

qs:= qs + x mod 10; 
x:= x/10; 
end loop ; 

put("Die Zahl"); put(xx,8); 
put("hat die Quersumme"); put(qs,5); 
new_l ine; 
end loop ; 


Hinweise: 

Eine Wiederholungsanweisunq mit for -Klausel beschreibt eine 
übliche Zählschleife mit der Schrittweite 1 oder -1. 

Mittels einer whij_e-Klausel oder exrt--AnWeisung kann man 
ferner jede beliebige Schleifenstruktur realisieren. 

Bei einer Zählschleife ist der Schleifenindex lokale Größe, 
also außerhalb der Wiederholungsanweisung unbekannt. 


4.6 MARKEN UND DIE SPRUNGANWEISUNG 

Eine Anweisunq kann mit einer oder mehreren Marken versehen 
sein. Solche Marken sind automatisch am Ende des Vereinba¬ 
rungsteils des innersten Rumpfes, in dem sie auftreten, ver¬ 
einbart. 
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Syntax: 

Aus 

ADA 23: ANWEISUNG 


MARKE —©— 


Semantik: 

Das Setzen einer Marke vor einer Anweisung erhält erst Be¬ 
deutung im Zusammenhang mit einer entsprechenden Sprunganwei¬ 
sung. Insbesondere wird die Wirkung der Anweisung durch das 
Setzen der Marke nicht verändert. Beim Setzen einer Marke 
ist zu beachten, daß eine Marke nur einmal in ihrem Gültig¬ 
keitsbereich zum Markieren einer Anweisung verwendet werden 
darf. 

Hinweis: 

Im Gegensatz zu PASCAL gibt es keinen Markenvereinbarungs¬ 
teil . 

Eine Sprunganweisung dient, wie der Name sagt, zum Springen 
an eine andere Anweisung des Programmes. Sie unterbricht al 
so die bisher gewohnte sequentielle Ausführung der Anweisun 
gen eines Programmes. 

Syntax: 

Aus 

ADA 23: ANWEISUNG 

-i£to — ZUN-MARKE-0- 


Semantik: 


Die Sprunganweisung goto y bewirkt, daß die Ausführung des 
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Programmes mit der markierten Anweisung <<y>>a fortgesetzt 
wird. (Die Marke y muß also die Anweisung markieren). 

Sprünge von außen in eine strukturierte Anweisung oder ei¬ 
nen Ausnahmebehandlungsteil sind ebenso verboten wie Sprün¬ 
ge zwischen verschiedenen Zweigen einer bedingten Anweisung, 
Auswahlanweisung oder select- Anweisung. Es darf nicht von 
einem Ausnahmebehandlungsteil zu einem anderen oder zu dem 
aufrufenden Block oder Rumpf zurückgesprungen werden. Außer¬ 
dem darf nicht aus einem Rumpf oder einer accept-Anweisung 
herausgesprungen werden. 

Es ist zu beachten, daß die Sprunganweisung goto y nur im 
Gültigkeitsbereich der Marke y auftreten darf. 

Hinweise: 

(1) Bei Verwendung von Sprunganweisungen stimmt die stati¬ 
sche Anweisungsfolge (der Niederschrift) nicht mehr mit 
der dynamischen Anweisungsfolge (bei der Ausführung) 
überein. Solche Programme sind deshalb 

- schwer zu lesen und zu verstehen 

- schwer zu korrigieren 

- bei Korrekturen schwerfällig. 

(2) Die Verwendung von Sprunganweisungen ist wegen der zu 
beachtenden Blockstruktur und wegen der Unsicherheiten 
bei strukturierten Anweisungen möglichst zu vermeiden. 

(3) Die Sprunganweisung kann mittels der Wiederholungsanwei¬ 
sung stets umgangen werden, was wegen (1) und (2) anzu¬ 
raten ist. 


4.7 DER UNTERPROGRAMMRÜCKSPRUNG 

Durch eine Rücksprunganweisung ( return -Anweisung) innerhalb 


eines Unterprogrammes wird die Ausführung des Unterprogram- 
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mes beendet und in die aufrufende Programmeinheit zurückge¬ 
sprungen. (Siehe 5.2). 


4.8 DIE AUSWAHLANWEISUN3 ( case -ANWEISUNS) 

Die Auswahlanweisung kann als Verallgemeinerung der beding¬ 
ten Anweisung (siehe Hinweis (1)) angesehen werden. Sie er¬ 
möglicht die Auswahl einer unter mehreren möglichen Anwei¬ 
sungen (Alternativen) in Abhängigkeit vom Wert eines Aus¬ 
druckes. Es kann also die auszuführende Alternative sozusa¬ 
gen berechnet werden. Damit stellt die Auswahlanweisung eine 
Verzweigung in eine vom Programmierer frei wählbare Anzahl 
von Richtungen dar. 

Syntax: 

Aus 

ADA 24: STRUKTURIERTE ANWEISUNG 

AuMMlilatv>KÄJ>una, 




.<D.: 

case — T AUSDR — j± - 

- when - 

- t EINF AUS —| • |.: 

- t INDEX BER 0-L ANW 


- when — 

- others -0-L -— 


Auiuiahtauickuck Ausuxihl 


Semantik: 

In Abhängigkeit vom Wert des Auswahlausdruckes wird genau 
eine der nachfolgend aufgelisteten Anweisungsfolgen ausge¬ 
führt. Dazu muß jeder Wert des Auswahltyps T in genau einer 
Auswahl auftreten. Die Ausdrücke in den Auswahlen sind sta¬ 
tisch. Gibt es einen others- Zweig, so faßt dieser alle 
nicht vorkommenden Werte zusammen. 

Mehrere Auswahlen vor einer Anweisung 
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when y 1 | y2 | ... | yn => a; 
sind äquivalent zu 

when yl => a; 
when y2 => a; 

. i 

when yn => a; 

oder, falls der Indexbereich yl .. yn genau die Werte yl,.., 
yn enthält, äquivalent zu 

when yl .. yn => a; 


Beispiele: 

1. case quad is 

when 1 => f:= phi * r; 
when 2|4 => f:= 90 * r; 
when 3 => f:= -(phi - 180) * r; 
end case ; 

2. case ch is 

when 1 a 1 | 1 A‘ => a:= a + 1; 
when 'e 1 | 1 E 1 => e:= e + 1; 

when 'i 1 | 1 1 1 => i:= i + 1; 

when 1 o 1 | 1 0' => o:= o + 1; 

when 'u* | 1 U' => u:= u + 1; 

when others => z:= z + 1; 
end case; 


Hinweise: 

(1) Die bedingte Anweisung 

if 3 then al; eise a2; end i f ; 
ist äquivalent der case -Anweisung 


10 Kaucher IV - ADA 
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case ß i_s when true => al; 

when false => a2; 

end case ; 

(2) Die Auswahlanweisung in PASCAL läßt als Auswahl nur Kon¬ 
stanten zu. 

(3) In anderen höheren Programmiersprachen wie BASIC, FOR¬ 
TRAN oder ALGOL 60 findet man eine ähnliche Anweisung 
unter dem Stichwort "berechnete Sprunganweisung". 


4.9 DER BLOCK 


Ein Block faßt eine Folge von Anweisungen zu einer einzigen 
zusammen. Ein Block kann einen Vereinbarungsteil und einen 
Ausnahmebehandlungsteil enthalten. Blöcke dienen als Struk- 
turierungsmittel, indem logisch zusammenhängende Anweisungen 
und die Vereinbarung der lokalen Typen, Konstanten und Vari¬ 
ablen sowie die Behandlung von Ausnahmen zu einer Einheit 
zusammengefaßt werden. 

Syntax: 

Aus 


ADA 24: STRUKTURIERTE ANWEISUNG 

Block 


1 


BL NAME -Oi 


declare-VEREINBTL 


- -1 begin l / 


1 ANW 

r exceptlon 

r AUSN BEHTL-. 



n 


■ end T BL NAME 


| BL NHTlt 1 


Semantik: 

Falls ein Blockname benutzt wird, so muß er am Anfang und 
Ende stehen. Der Vereinbarungsteil wird zuerst verarbeitet 
und dann der Anweisungsteil ausgeführt. 
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Bei spiel: 

Der Block 

fakultaet : declare 

i,fak_i : integer := 1; 
begin 

while i < n 
loop i:= i + 1; 

fak_i:= fak_i * i; 
end loop ; 
fak:= fak_i; 
end fakultaet; 

berechnet n! und weist diesen Wert der globalen Größe fak 
zu; n ist dabei eine globale Größe. 

Hinweise: 

(1) Die Verwendung eines Blockes entspricht dem Aufruf ei¬ 
ner argumentlosen Prozedur. 

(2) Blöcke können ineinander geschachtelt werden (vgl. Kap 

10 ). 

(3) Die Verwendung von Blöcken entspricht derjenigen in 
ALGOL 60. 

(4) Blöcke können zur Vereinbarung und Aktivierung von Pro 
zessen verwendet werden. 


'■MO DER AUFRUF EINER PROZEDUR 

Nach Ersetzen der formalen durch die aktuellen Argumente 
wird der Prozedurrumpf ausgeführt (siehe 5.3). 


10* 







148 


B.4 Anweisungen 


4.11 ANWEISUNGEN ZUR SYNCHRONISIERUNG VON 
PROZESSEN 

Zur Synchronisierung von Prozessen dienen vor allem der Ein¬ 
gangsaufruf, der eine Dienstleistung in einem anderen Pro¬ 
zeß aufruft, und die accept-Anweisung, die diesen Aufruf 
entgegennimmt. Diese beiden Anweisungen können auch als 
bedi ngter oder verzögerter Ein¬ 
gangsaufruf und als alternative 
a c c e p t -Anweisung formuliert werden. 

Ein Prozeß kann durch eine Verzögerungsan- 
Weisung in den Wartezustand versetzt werden und durch 
eine bedingte oder vorzeitige T e r m i- 
n i e r u n g beendet werden. 

Alle diese Anweisungen dürfen nur in Prozeßrümpfen oder de¬ 
ren Vorgänger auftreten. Eine genaue Beschreibung folgt in 
Kapitel 9. 


4.12 DAS AUSLÖSEN EINER AUSNAHME 

Durch eine raise-Anweisung wird eine Ausnahme ausgelöst und 
in den entsprechenden Ausnahmebehandlunqstei1 gesprungen 
(siehe Kapitel 7). 


4.13 DIE CODE ANWEISUNG 

Eine Code Anweisung ist ein qualifizierter Ausdruck, beste¬ 
hend aus einem Aggregat eines Record Typs, der eine in Ma¬ 
schinencode geschriebene Anweisung definiert. Solche Anwei¬ 
sungen können nur innerhalb einer inline-Prozedur auftreten, 
die nur Code-Anweisungen und im Vereinbarungsteil nur use - 
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Klauseln und Pragmas enthält. Diese Konstruktion dient dazu, 
Maschinencode in ein ADA-Programm einzubinden (siehe 8). 


4.14 BEISPIELE 

Beispiel 1: Bilden einer Quersumme 

Auf dem Datenteil stehen die Anzahl n und anschließend n na¬ 
türliche Zahlen. Das folgende Programm liest zunächst die 
ganze Zahl n und nacheinander die natürlichen Zahlen ein 
und druckt mit erläuterndem Text jeweils deren Quersumme 
aus. 

with standard_ea; use standard_ea; 
procedure beispiell 
n,qs,x,xx : integer; 
begin 
get(n); 
xx:= x; 
qs:= 0; 
while x > 0 
loop 

qs:= qs + x mod 10; 
x:= x/10; 
end 1oop ; 

put("Die Zahl"); put(xx,8); 
put("hat die Quersumme"); put(qs,5); 
new_l ine; 
end beispiell; 


Beispiel 2: Maschinenaddition (Rundungsfehler) 

Das Ergebnis einer Summation hängt beim Rechnen auf Rechen¬ 
anlagen von der Reihenfolge der auszuführenden Additionen ab. 
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B.4 Anweisungen 


Das folgende Programm berechnet die Summe 

s = ) (2' 29 + 2' v ) 

v=l(I)324 

einmal durch Summation "von links nach rechts" und ein 
zweites Mal von "rechts nach links", also 

T = l (2' 29 + 2' v ) 
v=324(-l)l 

Ausgedruckt werden die Werte S,T und die Differenz |S - T|. 

with standard_ea; use standard_ea; 
procedure beispiel2 is 
type real is^ digits 8; 
offset : real := 2.0 ** (-29); 
fakt : real := 2.0 ** (-324); 
faks : real := 0.5; 
s,t : real := 0.0; 
i : integer := 1; 
begin 

while i <= 324 
loop 

s:= s + (offset + faks); 
t:= t + (offset + fakt); 
faks:= faks/2.0; 
fakt:= fakt * 2.0; 
i: = i + 1; 
end loop ; 

put ("Summe S="); put (s, 12); newjine; 
put("Summe T="); put(t, 12); newjine; 
put("Differenz="); put(abs(s-t), 12); newjine; 
end beispiel2; 

Beispiel 3: (Meßwertaufgabe) 

Auf dem Datenteil stehen n Meßwerte , i = l(l)n, für eine 
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Größe s. Die Beurteilung eines Meßwertes erfolge nach fol¬ 
gender Tabelle: 


|x k - s| > 0.2 


"unbrauchbar" 

"schlecht" 

"brauchbar" 

"gut" 


0.2 > [x k - s| > 0.5i O -l 
0.5 io- 1 > |x k - s| > 0.1io-l 
0.1io-l > |x k - s| 


Folgendes Programm liest zunächst eine ganze Zahl n und den 
Wert s ein und druckt sodann von n einzulesenden Meßdaten 
die Anzahl der unbrauchbaren, schlechten, brauchbaren und 
guten Meßwerte gemäß obiger Tabelle aus. 

with standard_ea; use standard_ea; 
procedure bei spiel 3 is 
type real j_s digits 8; 

n,i»unbrauchbar, schlecht,brauchbar,gut : integer := 0; 
s,x,abso : real; 


begin 


get(n); get(s); 
loop 

get(x); 

abso:= abs(x - s); 
if abso <= 0.01 
then gut:= gut + 1; 
elsif abso <= 0.05 
then brauchbare brauchbar + 1; 
elsif abso <= 0.2 
then schlechte schlecht + 1; 
ei se unbrauchbare unbrauchbar + 1; 
end if ; 
i e i + 1; 
exit when i = n; 
end loop ; 

put("Es wurden"); put(n); 
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put_line("Messwerte eingelesen"); 
put("Davon waren"); put(gut); put_line("gut"); 

put(" "); put(brauchbar); 

put_line("brauchbar"); 
put(" "); put(schlecht); 

put_line("schlecht"); 
put( "); put(unbrauchbar); 

put_l ine("unbrauchbar"); 
end bei spiel 3; 

Beispiel 4: Suche von Extremwerten 

standard_funktionen sei ein vordefiniertes Bibliothekspaket, 
das u.a. die Funktion sqrt zur Berechnung der Quadratwurzel 
aus positiven Zahlen vom Typ real beinhaltet. 

with standard_ea,standard_funktionen; 
use standard_ea,standard_funktionen; 
procedure bei spiel 4 is 
type real j_s digits 8; 

max,min,absmax,absmin,x,absx,xx,y,ymax : real; 

i,n : integer; 

begin 

get(n); get(x); 
max:= x; min:= x; 
absmax:= abs(x); absmin:= absmax; 
ymax:= 0; 

i := 2; 

while i <= n 
loop 

xx:= x; get(x); absx:= abs(x); 
if_ x > max 
then max:= x; 
elsif x < min 


then min:= x; 
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end if ; 

if absx > absmax 
then absmax:= absx; 
eisif absx < absmin 
then absmin:= absx; 
end if ; 

y : = sqrt(abs(x - xx)); 
vf y > ymax 
then ymax:= y; 
end if ; 
i: = i + 1; 
end loop ; 

put("Groesster Wert max ="); 

new_l ine; 

put("Kleinster Wert min ="); 

new_l ine; 

put("Betragsgroesster Wert absmax="); 
new_line; 

put("Betragskleinster Wert absmin="); 
new_l ine; 

put("Folgenmaximum ymax ="); 

new_l ine; 
end bei spiel 4; 


put(max); 
put(min); 
put(absmax); 
put(absmin); 
put(ymax); 


Beispiel 5: Polynomauswertung (Hornerschema) und 
Tabel1ierung 

5 4 3 2 

Ein Polynom fünften Grades p(x) = a 5 x +a^x +a^x +a^x 4-a^+a^ 
soll im Intervall [a;b] an den Stützstellen x. ausgewertet 

L _ I 

werden; dabei ist h = —— , x^:= a und x.. + ^: = x^ + h , 
i = 0,...,n-l . Der Wert des Polynoms an der Stelle x be¬ 
rechnet sich nach folgendem Schema (HORNER-Schema) 


P(x) = ((((a 5 x+a 4 )x+a 3 )x+a 2 )x+a 1 )x+a 0 
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Das folgende Programm liest die Koeffizienten a^a^,...^ 
sowie a,b und n ein und druckt die Stützstellen , i=0(l)n, 
und die zugehörigen Polynomwerte sowie diejenigen Stütz¬ 
punkte aus, an denen der Polynomwert minimal bzw. maximal 
wird. 

with standard_ea; use standard_ea; 
procedure bei spiel 5 is 
type real i_s digits 8; 

a0,al,a2,a3,a4,a5,a,b,h,x,y,xmax,ymax,xmin,ymin : real; 

i,n : integer; 

begin 

get(a0);get(al);get(a2);get(a3);get(a4);get(a5); 
get(a);get(b) ;get(n); 
h:= (b - a)/n; 

— Tabellenüberschrift 
putjine(" x(1) y (x ( i )) **); 

x:= a; 

— Hornerschema für p(a) 

y:= ((((a5*x+a4)*x+a3)*x+a2)*x+al)*x+a0; 

put(x); put(y); new_line 

ymax:= y; ymin:= y; xmax:= x; xmin:= x; 

i: = 0; 

loop 

x:= x + h; 

— Hornerschema für p(a+i*h) 

v ^(a5*x+a4)*x+a3)*x+a2)*x+al)*x+a0; 

-- Tabellierung 
put(x); put(y); new_line 
-- Extremabestimmung 
i_f y > ymax 
then ymax: = y; 
elsif y < ymin 


then ymin:= y; 
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end j_f; 
i:= i + 1; 
exit when i = n; 
end loop ; 

put_line("Maximum:"); put(xmax); put(ymax); new_line; 
put_line("Minimum:"); put(xmin); put(ymin); new_line; 
end beispiel5; 

Beispiel 6: Vokale zählen 

Das folgende Programm bestimmt die Anzahl der einzelnen Vo¬ 
kale (groß und klein geschrieben) in einem Text. Es werden 
solange neue Zeichen des Textes eingelesen, bis das Ende 
des Datenteils erreicht ist, in dem der Text steht. Dies 
kann in ADA durch den booleschen Standardfunktionsaufruf 
end_of_file(input) geprüft werden. Ausgedruckt werden dann 
für jeden Vokal die gefundene Anzahl und schließlich die 
Zahl der sonstigen Zeichen. 

with standard_ea; use standard_ea; 
procedure bei spiel 6 is^ 

a,e,i,o,u,z : integer := 0; 
ch : character; 
begin 
loop 

get(ch); 
case ch is 


when 

1 a 1 |'A' 

=> a:= a 

+ 

l; 

when 

'e' | 1 E 1 

=> e:= e 

+ 

l; 

when 

'i' 

|T 

=> i:= i 

+ 

l; 

when 

V |'0' 

=> o:= o 

+ 

l; 

when 

1 u' 

|'U' 

=> u:= u 

+ 

l; 

when 

others 

=> z:= z 

+ 

1; 


end case ; 

exit when end_of_file(input); 
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end 1oop ; 

put_line(" Anzahl der Vokale "); 

put_l ine(" A E I 0 U "); 

put(a); put(e); put(i); put(o); put(u); 
new_line; 

put(z); put_line(" sonstige Zeichen"); 
end bei spiel 6; 

Beispiel 7: 

Das folgende Programm tabelliert unter Verwendung der Aus¬ 
wahlanweisung die mit den Polarkoordinaten r und <f> definier¬ 
te Funktion f(<j>,r) in der komplexen Zahlenebene C auf dem 
Ursprungskreis mit Radius r, beginnend mit dem Winkel <j> = 0 
in der Schrittweite h. Radius und Schrittweite werden einge¬ 
lesen. 

r 

<{> • r 0 <_ 4» < 9 0 , r _> 0 

4 90 • r 90 < <J> < 180 , r _> 0 

-(<f> - 180)• r 180 <_ (j> < 270 , r _> 0 

- 90 • r 270 < <j> < 360 , r > 0 

v. 

with standard_ea; use standard_ea; 

procedure tabelle is^ 

quad : integer; 

f,r,h,phi : float; 

begin 

get(h); get(r); phi:= 0; 
while phi <= 360 
loop quad:= integer(phi/90) + 1; 
case quad is 

when 1 => f:= phi * r; 

when 2 => f:= 90 * r; 

when 3 => f:= -(phi - 180) * r; 

when 4 => f:= -90 * r; 


end case; 
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put("radius="); put(r); 
put("winkel = "); put(phi); 
put("funktionswert="); put(f); 
phi:= phi + h; 
end loop ; 
end; 
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5. HANDHABUNG VON UNTERPROGRAMMEN 

Ein UNTERPROGRAMM ist eine ausführbare Programmeinheit, wel¬ 
che durch einen Unterprogrammaufruf angestoßen, d.h. zur Aus¬ 
führung gebracht wird. Es besteht aus der UNTERPROGRAMM 
SPEZIFIKATION und dem Un£eAp*og*ammAump6. 

Die Unterprogrammspezifkation beschreibt die Schnittstelle 
des Unterprogramms zu anderen Programmeinheiten; in ihr sind 
also alle für den Aufruf wichtigen Informationen zusammenge¬ 
faßt. 

Im einzelnen sind dies der Name des Unterprogramms sowie die 
formale Argumentliste. Beim Aufruf werden die formalen Argu¬ 
mente durch die aktuellen ersetzt. Die aktuellen Argumente 
dienen dazu, Daten in das Unterprogramm einzubringen oder 
Ergebnisse herauszureichen. 

Der Unterprogrammrumpf beschreibt die Aktion des Unterpro¬ 
gramms, d.h. die auszuführende Anweisungsfolge. Ein Unterpro¬ 
gramm wird immer dann verwendet werden, wenn die gleiche An¬ 
weisungsfolge mehrfach - eventuell mit verschiedenen Daten - 
ausgeführt werden soll. Doch aus Gründen der Lesbarkeit, 
Übersicht und besseren Strukturierung eines Programmes wird 
empfohlen, zusammengehörige Anweisungsfolgen stets als Unter¬ 
programm zu formulieren, auch wenn sie nur einmal ausgeführt 
werden, z.B. Initialisierung oder Ausdrucken von Ergebnissen. 


5,1 DIE VEREINBARUNG VON UNTERPROGRAMMEN 

Die Vereinbarung von Unterprogrammen wurde in 1.1 einführend 
behandelt. Wir wiederholen hier kurz. 


5.1 Vereinbarung von Unterprogrammen 
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Syntax: 

ADA 6: UNTERPROGRAMM (UPG) 


• UPG SPEZIF — li j VEREINBTL —. 

I-L begln 1 / 


y exceptlon -j- AUSN BEHTL-1 

I-1-L end -p- 


end 1- PZD NAME - 
- T FKT NAME 
T OPERATOR - 


UnteipxogKtomnunp^ 


ADA 7: UNTERPROGRAMM SPEZIFIKATION (UPG SPEZIF) 

0 » (B,CH,AZ,I.G.F.A.ST.REC.ZJ , * « {IF,OF.IOF,ITF,OTF) 



Die Verarbeitung einer UNTERPROGRAMMSPEZIFIKATION wird, auch 
wenn diese wiederholt wird, nur einmal vorgenommen. Sie be¬ 
ginnt mit der Einführung des Namens, es folgt die Verarbei¬ 
tung der formalen Argumente in der Reihenfolge ihres Auftre¬ 
tens und bei Funktionen oder Operatoren die Verarbeitung des 
Ergebnistyps. 


Synta x: 


ADA 27: FORMALE ARGUMENTLISTE (FOR ARG LISTE) 

e * (B.CH.AZ.I,G.F.A.ST.REC.ZJ * » {IF ,OF , IOF,ITF,OTF) 


id> 




■O 


| T6ou»u(PZS) ] r VAR NAME —LQ. 


- out —| 

— 1n-out —I- T TYP ■ 


- T ausdr 


fowites 
A\giunent iüA 


Ausgabe 

-©—| bin-/Ausgabe 


Initiatisiciung 
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Semantik: 

Die Namen der formalen Argumente werden eingeführt. Diese 
gelten in dem gesamten Unterprogramm als lokale Variable oder 
Konstanten vom angegebenen Typ. Außerdem wird der Übergabe¬ 
modus (Eingabe, Ausgabe, Ein/Ausgabe) festgelegt. 

Innerhalb einer Typangabe oder eines Anfangswertes darf kein 
anderes formales Argument auftreten. Die Anfangswerte müssen 
zur Übersetzungszeit berechnet werden können. 

Funktionen dürfen nur Eingabeargumente haben. 

Prozesse können nur als Eingabeargumente auftreten. 

Einstellige Operatoren haben ein Eingabeargument. Zweistelli¬ 
ge (das sind alle anderen) haben zwei Eingabeargumente. An¬ 
fangswerte sind nicht zugelassen. 

Beispiele: 

1. Funktionsvereinbarung aus 5.8, Beispiel 2 

function binom (m,n : in^ integer) re turn integer i_s_ 

i,k : integer := 1; 

begin 

if (m >= n) and (n > 0) 
then whi1e i < n + 1 loop 

k:= (k * (m - i + 1))/i; 
i: = i + 1; 
end loop ; 

end if ; 

vf m < n then k: = 0; end if ; 
return k; 
end binom; 


2. Die folgenden Funktionen dienen zur 
- nicht-rekursiven Berechnung von n! 











5.1 Vereinbarung von Unterprogrammen 


161 


function fak (n : in_ integer) re turn integer is_ 

i,fak_i : integer := 1; 

begin 

while i < n loop 
i: = i + 1; 
fak_i := fak_i * i; 
end loop ; 
return fak_i; 
end fak; 

- rekursiven Berechnung von n! 

function rek_fak (n : in integer) return integer is 
begin 

if n = 0 then return 1; 

eise return rek fak (n-1) * n; 

end if ; 
end rek_fak; 

3. Die Prozedur halb berechnet die Nullstelle 5 der Funktion 
2 

f(x) = x - cl im Intervall [a^,b^], 0 < < b^ . Be¬ 

ginnend mit dem Ausgangsintervall [a^b^], das 5 enthält, 
wird das jeweils berechnete Intervall solange verkleinert 
(halbiert), bis der Durchmesser kleiner als epsl ist. 

procedure halb (cl,epsl : float, al,bl : in out float) is 
m : float; 
begin 
loop 

m: = (al + bl) * 0.5; 

vf m * m - cl >= 0 then bl: = m; 

el se a 1: = m; 

end if ; 

exit when bl - al < epsl; 
end loop ; 
end halb; 


11 Kaucher IV - ADA 
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4. Operatorvereinbarung für Vektoraddition 


function "+" (x,y : vektor) re turn vektor is^ 

resultat : vektor(x'ränge); 

begin 

for index i_n x'ränge 
loop 

resultat(index):= x(index) + y(index); 
end loop ; 
return resultat; 
end "+"; 

Hinweise: 

Die formalen Eingabeargumente werden innerhalb des Unterpro¬ 
grammes wie lokale Konstante, die anderen wie lokale Varia¬ 
ble behandelt. Ihre Namen dürfen also nicht im Vereinbarungs¬ 
teil des Unterprogrammrumpfes überschrieben werden. 

Der Übergabemechanismus wird in 5.6 beschrieben. 


5.2 DER UNTERPROGRAMMRÜCKSPRUNG 

Syntax: 

Aus 


ADA 23: ANWEISUNG (ANW) 

UnteA.pn.OQ narmnücki pnung 


- return 


reou» 


r AUSDR 


ZI 


RücfeipAtwg am Funktion öden. Openaton 
Rückip-nung am Pnozedun öden acccDt-Anw&üung 


Funktioniuient 


Semantik: 

- Durch einen Unt&iptiogsiammückApnung (Rücksprunganweisung, 
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return-Anweisung) innerhalb eines Unterprogramms wird die 
Ausführung des Unterprogramms beendet und in die aufrufen¬ 
de Programmeinheit zurückgesprungen. 

- Oer Typ des Funktionswertes muß gleich dem Ergebnistyp der 
Funktion sein. 

- Die Ausführung einer Prozedur wird auch korrekt beendet, 
falls das Ende des Anweisungsteils erreicht ist, eine 
Funktion muß dagegen mit einer Rücksprunganweisung verlas¬ 
sen werden, da nur dadurch der Funktionswert festgelegt 
wird. Wird bei einer Funktion das Ende des Anweisungstei1s 
erreicht, so ist der Wert der Funktion unbestimmt. 

- Eine Rücksprunganweisung kann innerhalb einer inneren 
Schleife eines Unterprogramms stehen, alle Schleifen wer¬ 
den dann korrekt beendet und der Rücksprung erfolgt. 

- Eine Rücksprunganweisung darf nur im Anweisungsteil eines 
Unterprogrammrumpfes oder einer accept-Anweisung stehen. 
Dort kann sie selbstverständlich mehrfach auftreten. 

Beispiel: 

return ; -- Ruecksprung aus einer Prozedur 

return (3 + i) * x; -- Ruecksprung aus einer Funktion 
-- Als Funktionswert wird der Wert des Aus- 
— drucks (3 + i)x übergeben. 


11* 
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5.3 DER AUFRUF EINER PROZEDUR 

Syntax: 

Aus 

ADA 23: ANWEISUNG (ANW) 


Au^/iu^ von 


r— FILE VERWALTUNGS PROZEDUR AUFRUF- 

1 , 

— EIN/AUSGABE PROZEDUR AUFRUF - 

| Standard- 

— ZUN — PZD NAME —r— AKT ARG LISTE —, 

iilbhtdii. 

X 1 



Der Aufruf von Standardprozeduren zur Fileverwaltung und 
Ein/Ausgabe hat die gleiche Form wie der Aufruf selbstdefi¬ 
nierter Prozeduren. Die genaue Behandlung der Standardpro¬ 
zeduren erfolgt in Kapitel 11. 

Semantik: 

Der Aufruf einer Prozedur bewirkt die Ersetzung der forma¬ 
len durch die aktuellen Argumente (siehe 5.6) und die Aus¬ 
führung des entsprechenden Prozedurrumpfes. 

Beispiel: 

halb(2,1.0e-5,0,2); 

berechnet mit der Genauigkeit 10~ 5 . 


5,4 DER AUFRUF EINER FUNKTION 


Der Aufruf einer Funktion erfolgt innerhalb eines Ausdrucks. 
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Syntax: 


Aus 

ADA 31: r OPERAND (r OPD) 


T Funktioniaui'iul 


Aufuij 


je( B.I.ST.ITF.OTF) )— t E/A STANDARD FUNKTIONS AUFRUF ■ 

ITG0 O U{F,G.ST) )-r ATTR FKT AUFRUF - 

(reu, f.g) )- (TbT) - 


■ T AUSDR ■ 


-Gh 


■ ZUN 


■ t FKT NAME — AKT ARG LISTE ■ 


•o 


T E{A,ST.Z) I T, G0 n 

- -ZUN- t 2 FKT NAME — AKT ARG LISTE -Q-- . 1 3 0 t 5 AUSDR 

T, 60, 


t 4 6(REC,Z} 


ZUN- r 4 FKT NAME — AKT ARG LISTE — Q- 


-°° D t 5 INDEX BER^—L-0- 


■ t KOMP NAME - 


Funktion 


ietbitdc^. 

Funktion 


Komponenten- 
tjp T 


Der Aufruf von Standardfunktionen für Ein- und Ausgabe wird 
in Kapitel 11 behandelt. Die attributierten Funktionen so¬ 
wie die Standardfunktion abs wurden in Kapitel 3 bei den 
Ausdrücken für die einzelnen Typen behandelt. 


Semantik: 

- Die Auswertung des Ausdrucks wird unterbrochen. Die for¬ 
malen Argumente werden durch die aktuellen ersetzt und 
das Ergebnis gemäß dem Funktionsaufruf bestimmt. 

- Bei Funktionen von strukturiertem Ergebnistyp kann auf 
die Komponenten zugegriffen werden wie bei Variablen. 


Beispiel: 

Die Anweisung 

m:= binom (n-t,s-k); 
weist m den Wert ("l^) zu. 
Der Aufruf 

f:= rek_fak (2 * j - 1); 


bewirkt für j = 2 die Zuweisung des Wertes 6 an f. 






























166 


B.5 Unterprogramme 


Hinweis : 

Eine Funktion berechnet einen Wert und sollte keine Neben¬ 
wirkungen auf globale Größen haben. 


5,5 DER AUFRUF EINES OPERATORS 

Ein Operator hat ein oder zwei Eingabeargumente. Diese dür¬ 
fen nicht mit Anfangswerten vorbesetzt sein. 

Ein einstelliger Operator wird aufgerufen, indem das Opera¬ 
torzeichen vor das aktuelle Argument geschrieben wird, ein 
zweistelliger, indem das Operatorzeichen zwischen die beiden 
aktuellen Argumente geschrieben wird. 

In Kapitel 3 (Ausdrücke) wurden die vordefinierten Operato¬ 
ren besprochen und die Syntax für das allgemeine Operator- 
konzept dargestellt. 

Beispiel: 

Die Anweisung 
c:= a + b; 

berechnet mit den 3 Vektoren a,b,c die Summe a + b und weist 
das Ergebnis an c zu. Dabei wurde die Operatorvereinbarung 
für den Operator + von 5.1, Beispiel 4 vorausgesetzt. 




5.6 Zusammenspiel der Argumente 


167 


5.6 DAS ZUSAMMENSPIEL DER FORMALEN UND DER 
AKTUELLEN ARGUMENTE 


Syntax: 


ADA 3A: AKTUELLE ARGUMENTLISTE (AKT ARG LISTE) 

e - (B.CH.AZ.I.G.F.A.ST.REC.Z) . » ■ {IF.OF.IOF.ITF.OTF) 



Semantik: 

-Die aktuellen Argumente werden den formalen in der Reihen¬ 
folge von links nach rechts zugeordnet (Zuordnung nach. 
Reihenfolge.), oder sie ersetzen das formale Argument, des¬ 
sen Name angegeben wurde (Zuordnung nach Namen). 

- Hat ein formales Argument einen Anfangswert (default) 

(nur bei Eingabeargumenten), so kann das aktuelle Argu¬ 
ment hierfür fehlen, es wird dann mit dem Anfangswert ge¬ 
rechnet. 

- Fehlt aus diesem Grund ein aktuelles Argument oder wurde 
einmal die Ersetzung durch Angabe des formalen Argument¬ 
namens durchgeführt, so müssen alle weiteren Argumente 
durch Angabe des formalen Argumentnamens ersetzt werden. 

- Aktuelle Ein/Ausgabe- oder Ausgabeargumente sind Variable 
oder Typkonversionen von Variablen. 

- Die aktuellen Argumente müssen vor dem Aufruf alle Ein¬ 
schränkungen der formalen erfüllen. Für Ausgabeargumente 
für skalare Typen und Zeigertypen genügt es, wenn die 
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formalen Argumente die Einschränkungen der aktuellen Ar¬ 
gumente vor dem Rücksprung erfüllen. 

- Die Auswertung der Ausdrücke oder Komponentenauswahl etc. 
erfolgt vor der Ausführung des Rumpfes. 

- Die Reihenfolge der Argumentauswertung ist nicht festge¬ 
legt. 

- Die aktuelle Argumentliste für Funktionen ohne formale 
Argumente und für Prozeduren, in denen für alle Argumente 
die Standardanfangswerte verwendet werden sollen, besteht 
aus ( ). 

- Der Aufruf von Prozeduren ohne formale Argumente ge¬ 
schieht nur durch Angabe des Namens. 

- Bei Funktionen sind nur Eingabeargumente zulässig, es müs¬ 
sen eine oder mehrere Rücksprung-(return-) Anweisungen 
Vorkommen (s. 5.2). Wird die Funktion nicht durch eine 
Rücksprunganweisung verlassen, so ist der Wert Undefi¬ 
niert. 

- Aktuelle Eingabeargumente vom limitierten, geschützten 
Typ können auch Prozesse sein. 

- Eingabeargumente fungieren als lokale Konstante des Unter¬ 
programmes, deshalb darf ihr Wert innerhalb des Rumpfes 
nicht verändert werden. Für skalare Typen und Zeigertypen 
wird der Wert des aktuellen Argumentes in das formale Ar¬ 
gument kopiert. 

- Ausgabeargumente (Argumente für Variable) dienen dazu, Er¬ 
gebnisse aus einer Prozedur zu liefern. Für skalare Typen 
oder Zeigertypen wird der Wert des formalen Argumentes 
beim Prozedurrücksprung in das aktuelle Argument kopiert. 
Bei Typkonvertierung für Variable wird vor der Ergebnis¬ 
rückgabe die inverse Typkonvertierung durchgeführt. 

- Für strukturierte Typen ist der Übergabemechanismus für 
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Ein- und Ausgabe nicht festgelegt. 


5.7 DAS ÜBERLADEN VON UNTERPROGRAMMEN 

Namen von Unterprogrammen (also auch Operatoren) können 
mehrfach belegt werden. Ein Unterprogramm wird also durch 
seinen Namen, die Anzahl, Reihenfolge, Namen und Typen sei¬ 
ner Argumente, das Vorhandensein von Anfangswerten für spe¬ 
zielle Argumente und bei Funktionen auch durch den Ergebnis¬ 
typ identifiziert. Unterscheiden sich deshalb zwei Unterpro¬ 
gramme nur in mindestens einem dieser Punkte, so sind sie 
unterscheidbar und können daher beide gleichzeitig benutzt 
werden. Beim Aufruf solcher Unterprogramme muß eindeutig 
feststellbar sein, welches gemeint ist. Sonst liegt ein Feh¬ 
ler vor. Unterscheiden sich z.B. zwei Unterprogramme nur 
durch den Namen der formalen Argumente, so müssen zur ein¬ 
deutigen Identifizierung die aktuellen Argumente mit dem 
Namen des formalen Argumentes angegeben werden. 

Beispiel: 

Die Operatorvereinbarung von 5.1, Beispiel 4 versieht den 
arithmetischen Standardoperator + mit einer zusätzlichen Be¬ 
deutung: Addition für Vektoren. 
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5.8 BEISPIELE 
Beispiel 1: 

In der folgenden Prozedur wird j! für j = l,2,...,k berech¬ 
net. 

w ith standard_ea; 
procedure fakultaeten is 
use standard_ea; 
j,k : integer; 

function fak(n : in_ integer) return integer 
is i,fak i : integer := 1; 
begin 

while i < n loop 
i: = i + 1; 
fak i:= fak_i * i; 
end loop ; 
return fak_i; 
end fak; 
begin 

get(k); j:= 0; 
while j < k loop 
j•= j + i; 

put(j); 
put(fak(j)); 
new_l ine; 
end loop ; 
end fakultaeten; 

Beispiel 2: 

Ein Kartenspiel mit n Karten werde so verteilt, daß jeder 
Spieler s Karten erhält. Befinden sich t Trümpfe im Karten¬ 
spiel, so berechnet sich die Wahrscheinlichkeit w(k), daß 
ein bestimmter Spieler genau k Trümpfe erhält, wie folgt: 
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(k) <s-k> 

w(k) = k s k , k = 0(l)t . 

(!) 

Für j Datensätze n,t,s sind die Wahrscheinlichkeiten w(0), 
w(l),...,w(t) zu berechnen. 

with standard_ea; 
procedure trumpf is 
use standard_ea; 
j,k,n,s,t : integer; 
w : float; 

function binom (m,n : in_ integer) return integer is_ 

i ,n : integer := 1; 

begin 

if (m >= n) and (n > 0) 

then while i < n + 1 loop 

k:= (k * (m - i + l))/i; 
i: = i + 1; 
end loop ; 

end if ; 

if_ m < n then k:= 0; end i f ; 
return k; 
end binom; 

begin -- Hauptprogramm 

get(j); 

while j > 0 loop 
get(n); 
get(t); 
get(s); 
put("n=“); 
put(n); 

put("ut=''); put(t); put("uS="); put(s); new_line(2); 


k:= 0; 

while k <= t loop 
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w:= real(binom(t,k)*binom(n-t,s-k)/binom(n,s)); 
put("Wahrscheinlichkeit-fueru"); put(k); 
put("uTruempfeu,:-") ;put(w) ;new_l ine; 
k:= k + 1; 
end loop ; 
new_l ine; 
j:= J - 1; 
end loop ; 
end trumpf; 

Beispiel 3: 

Gegeben sei das Anfangswertproblem 

y' = f(x»y). y(x 0 ) = y 0 

im Intervall [a,b]. Wir wollen im folgenden Programm die Lö¬ 
sung y(x) an den Stellen x.: = a + j • h, j = 0,1,...,n, mit 
b - a J 

h:= —-— näherungsweise bestimmen. Wir verwenden dazu ne¬ 
beneinander drei numerische Verfahren: 

Euler-Verfahren: 

y j+i := y j + h • j 

Verbessertes Euler-Verfahren: 

x j+l : “ y j + ?< f ( x j> y j> + ^ (xj+h ,y d +h --f (xj orj))). 

j = 0,1,...,n-l 


Runge-Kutta-Verfahren: 

y j+l := y j + W 4k 2 +k 3> mit 
k l := f ( X j’ y j) 
k 2 := f(x j + ?’ y j + ? k l ) 
k 3 : = f(Xj+h,yj-hk^+2hk2) 

j = 0,1,...,n-l 
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Dabei bedeutet y. jeweils die durch das Verfahren berechnete 
J 

Näherung für den Funktionswert y(xj). 

Die Verfahren werden für f(x,y) = e’ y durchgeführt und die 
Näherungswerte mit den entsprechenden Funktionswerten der 
exakten Lösung y(x) = ln x verglichen. 

with standard_ea, standard_funktionen; 

procedure bei spiel 3 i_s — numerische Loesung des Anfangs- 

-- Wertproblems 

use standard_ea, standard_funktionen; 
X,y,y0,yl,y2,y3,a,b,h,kl,k2,k3 : float; 
i,n : integer; 

functi on f (x,y : j_n float) re turn float is 
begin 

return exp(-y); 
end f; 

begin — Beispiel 3 

get(a); get(b); get(y0); get(n); 

-- Ueberschrift 

Put("„ üuijü x uuuuij yl <j „„ üü y2 uuüuu y3 tiuuuu y(x)"); 

y l: = y0; 

y2:= y0; 

y3:= y0; 

i:= 1; 

x:= a; 

h:= (b - a)/float(n); 
y:= ln(x); 
put(x,width => 6); 
put(yl,6); 
put(y2,6); 
put(y3,6); 
put(y,6); 
while i <= n loop 


-- Euler-Verfahren 
yl:= yl + h * f(x,yl); 
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-- Verbessertes Euler-Verfahren 

y2: = y2 + h/2 * (f(x,y2)+f(x+h,y2+h*f(x # y2))); 

-- Runge-Kutta-Verfahren 
kl:- f(x,y3); 

k2:= f(x + h/2,y3 + h/2 * kl); 
k3:= f(x+h,y3-h*kl+2*h*k2); 
y3:= y3 + h/6 * (kl + 4 * k2 + k3); 

-- Berechnung des Arguments 
x:= x + h; 

-- Vergleichswert y(x) 
y:= 1 n (x); 

-- Tabellierung 

put(x,width => 6); put(yl,6); put(y2,6); put(y3,6); 
put(y,6); 
i: = i + 1; 
end loop ; 
end beispiel3; 



6. Programmschemata 


175 


6. HANDHABUNG VON PROGRAMMSCHEMATA 


Unterprogramme beschreiben Anweisungsfolgen, die zur Lauf¬ 
zeit (Ausführungszeit) durch Aufruf mit verschiedenen aktu¬ 
ellen Argumenten ausgeführt werden. Als Argumente können Aus¬ 
drücke und Variable angegeben werden. Oft kommt es vor, daß 
gleiche Anweisungsfolgen für verschiedene Typen gebraucht 
werden, z.B. die Verwaltung einer Liste, deren Grundtyp eine 
beliebige, für die Listenverwaltung nicht interessierende Da¬ 
tenstruktur sein kann, oder Matrizenrechnung für reelle bzw. 
komplexe Matrizen. Oder man benötigt ein Unterprogramm, das 
man in gleicher Weise auf verschiedene Funktionen anwenden 
will, z.B. ein Integrationsverfahren. 

Nicht nur Unterprogramme sondern auch Pakete sollten para- 
metrisiert vorliegen, d.h. mit verschiedenen Argumenten be¬ 
legt werden können. 

Für diesen Zweck stehen in ADA die Schemata für Unterprogram¬ 
me und Pakete zur Verfügung. Ein Schema (eine generi¬ 
sche Programmeinheit) ist dabei eine S c h a b 1 o n e , die 
eine ganze Klasse von ähnlichen Programmeinheiten (Unterpro¬ 
grammen, Paketen) beschreibt. 

Während der Übersetzungszeit können durch eine UNTERPROGRAMM¬ 
ERZEUGUNG oder PAKETERZEUGUNG verschiedene Ausprä¬ 
gungen (Inkarnationen) dieser Schablone hergestellt 
werden, die dann wie normale Unterprogramme oder Pakete be¬ 
handelt werden. 

Für verschiedene Aktionen sind Programmschemata vordefiniert. 
Von diesen Schemata können ohne vorherige Vereinbarungen Aus¬ 
prägungen erzeugt werden. Diese Schablonen treten vor allem 
bei der Ein- und Ausgabe auf (siehe 4.3 und 11), sowie bei 
der unkontrol1ierten Speicherfreigabe (8.3) bzw. Typumwand- 
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lung (8.4) und bei der Verwaltung gemeinsamer Variablen von 
Prozessen (9.7). 

6.1 DIE VEREINBARUNG VON SCHEMATA 
Syntax: 

ADA 3: UNTERPROGRAMM SCHEMA SPEZIFIKATION 
- generic — FOR SCH ARG LISTE — UPG SPEZIFIKATION - 

ADA 4: PAKET SCHEMA SPEZIFIKATION 

- generic — FOR SCH ARG LISTE — PAK SPEZIFIKATION - 

ADA 5: FORMALE SCHEMA ARGUMENT LISTE (FOR SCH ARG LISTE) 

0 « (B,CH,AZ,I,G,F,A,ST,REC,Z) ♦ - {I F,OF ,IOF,I TF,OTF} 0 D * {B.CH.AZ.IJ 


FoAmoZe Kxgumwte. &ÜA.: 



- Für ein Unterprogramm, das als Schema vereinbart wird, 
müssen Spezifikation und UNTERPROGRAMM getrennt angegeben 
werden. Im Unterprogrammrumpf werden die formalen Schema¬ 
argumente verv/endet. Bei der Unterprogrammerzeugung werden 
in der Spezifikation und im Rumpf die formalen Schemaargu- 
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mente durch aktuelle ersetzt. 

Besteht ein Paket, das als Schema vereinbart wird, aus 
Spezifikation und Rumpf, so können im Rumpf die formalen 
Schemaargumente der Spezifikation verwendet werden. Bei 
der Paketerzeugung werden in Spezifikation und Rumpf die 
formalen Schemaargumente durch aktuelle ersetzt. 

Bei der Verarbeitung einer Schemaspezifikation wird zu¬ 
erst der Name des Schemas eingeführt, dann folgt die Ver¬ 
arbeitung der formalen Schemaargumente in der gegebenen 
Reihenfolge. 

Ein formales Schemaargument kann von einem anderen abhän- 
gen, falls dieses ein Typargument ist und vorher in der 
formalen Schemaargumentliste auftritt. 

Ausdrücke für Anfangswerte, die von formalen Schemaargu¬ 
menten abhängen, werden erst während der Erzeugung ausge¬ 
wertet. 

Formale Schemaargumente dürfen nicht als Auswahl marken, in 
integer Typdefinitionen oder Genauigkeitseinschränkungen 
auftreten. 

Für formale Schemaargumente für Ein- und Ausgabe von Wer¬ 
ten muß die Zuweisung möglich sein. (Also sind keine 
Files oder Prozesse erlaubt). 

Man beachte, daß keine reinen Ausgabeargumente erlaubt 
sind. 

Formale Schemaargumente für Typen werden verarbeitet wie 
Typvereinbarungen. 

Es stehen alle vordefinierten Operationen, Konstanten 
(auch attributierte) und attributierten Funktionen, außer 
image und value, zur Verfügung. Zum Beispiel werden Arrays 
in der üblichen Weise indiziert und für integer Typen ste¬ 
hen die Operationen zur Verfügung. 
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Für geschützte Typen müssen alle Operationen über formale 
Schemaargumente für Unterprogramme zur Verfügung gestellt 
werden, nur Zuweisung und Vergleich auf Gleichheit oder 
Ungleichheit sind bekannt. 

- Formale Schemaargumente für Unterprogramme können selbst¬ 
verständlich formale Argumente haben, die auch von forma¬ 
len Schemaargumenten für Typen abhängen können. Ist eine 
l/osiauAwakl anqeqeben, so wird bei der Erzeugung ein Unter¬ 
programm dieses Namens bzw. ein beiiebiges »passendes 
(falls Vorauswahl <>) eingesetzt, falls ein aktuelles 
.Schemaargument fehlt. 

- Prozeßtypen können nicht als formale Schemaargumente auf- 
treten, da durch Angabe eines Prozeßtyps alle Objekte die¬ 
ses Prozeßtyps festliegen und ihren Wert nicht ändern kön¬ 
nen. Demzufolge könnte auch kein anderer Prozeßtyp als ak¬ 
tuelles Schemaargument übergeben werden. 

Hinweise: 

Wesentlich neu im Vergleich zu Unterprogrammen ist die Über¬ 
gabe von Typen und Unterprogrammen als Argumente. 

Bei den Schemaargumenten für Typen sollte man den Typ so¬ 
weit wie möglich kennzeichnen, da dann die vordefinierten 
Operationen bekannt sind und während der Übersetzungszeit 
mögliche Prüfungen ausgeführt werden können. 

Soll ein Schema für verschiedene Typen (Typklassen) ange¬ 
wandt werden, so müssen diese als geschützte Typen überge¬ 
ben werden. 

Es können nun auch Pakete parametrisiert werden. Innerhalb 
einer SchemaVereinbarung oder dem entsprechenden Rumpf kön¬ 
nen globale Größen auftauchen; das sind Größen, die 
in einer die Schemavereinbarung oder den Rumpf umfassenden 
Programmeinheit vereinbart wurden. 
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Ein Unterprogrammrumpf muß stets vorhanden sein. Man kann 
nicht zu einer Unterprogrammschemaspezifikation mehrere 
aktuelle Rümpfe schreiben und nur die Spezifikation anwen¬ 
den. 

Beispiele: 

1. Zeigerverwaltung 

Das Paketschema zeiger_verwaltung stellt dem Benutzer die 
Möglichkeit der "garbage collection" zur Verfügung. Es 
wird der zeiger_typ definiert, mit dem die Komponenten 
einfach verkettet werden. Das Paket enthält die Prozedu¬ 
ren ablegen und holen, um ein überflüssig gewordenes 
Listenelement an die Liste anzuhängen bzw. ein Listenele¬ 
ment aus der Liste zu entnehmen. Erst wenn die Liste leer 
ist, wird in holen ein neues Listenelement erzeugt. 

qeneric 

type komponente i_s_ private ; 
package zeiger_verwaltung is_ 
type komponenten_rahmen; 

type zeiger_typ is_ access komponenten_rahmen; 
type komponenten_rahmen is 
re cord 

daten : komponente; 
nachfolger : zeiger_typ; 
end record ; 

procedure ablegen (zeiger : in out zeiger typ); 
procedure holen (zeiger : out zeiger typ); 
end zeiger_verwaltung; 

package body zeiger_verwaltung is 

1 isten_anfang : zeiger_typ := nul 1 ; 

procedure ablegen (zeiger : in out zeiger typ) is 


12* 
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begin 

zeiger.nachfolger: = 1 isten_anfang; 
listen_anfang:= zeiger; 
zeiger:= null; 
exception 

when constraint_ error => nul 1 ; 

-- wird ausgeloest, wenn zeiger = null war, 
-- also ab!egen mit einem unbelegten Zei- 
-- ger aufgerufen wurde. 
end ablegen; 

procedure holen (zeiger : out zeiger_typ) is 
begin 

if listen_anfang = null 

then zeiger:= new komponenten_rahmen; 
else zeiger:= 1isten_anfang; 

listen_anfang:= listen_anfang.nachfol ger; 
zei ger,nachfol ger:= null; 
end if ; 
end holen; 

end zeiger_verwaltung; 

2. Horner-Schema für Polynome beliebigen Grades mit Koeffi¬ 
zienten beliebigen Typs 

generic 

type koefftyp private ; 

type polynom is_ array (integer ränge <> ) of koefftyp; 
with function "+" (a,b : koefftyp) return 
koefftyp is_ "+"; 

with function (a,b : koefftyp) return 
koefftyp j_s 

function horner (a: polynom; x : koefftyp) return koefftyp; 

function horner (a:polynom; x: koefftyp) return koefftyp 
is z : koefftyp; 
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begin 

z:= a(a'last); 

for i j_n reverse a'first .. a'last - 1 

10OP 

z:= z * x + a(i); 
end loop ; 
return z; 
end horner; 


5.2 DIE AUSPRÄGUNG VON SCHEMATA 

Ein Programmschema (Unterprogrammschema oder Paketschema) 
ist noch keine fertige direkt verwendbare Programmeinheit. 
Erst durch die während der Übersetzungszeit vorgenommene 
PAKETERZEUGUNG bzw. UNTERPROGRAMMERZEUGUNG werden weiterver¬ 
wendbare Pakete bzw. Unterprogramme erstellt. 

Syntax: 

AUS ADA 8: UNTERPROGRAMM ERZEUGUNG 

O = {B,CH,AZ,I,G.F,A,ST,REC,Z} ♦ - (1F,0F,10F,ITF,0TF) 

erzeugte P/iog/uumeÄnheit Name des ScAemai 

- procedure — PZD NAME — ii - new - ZUN - PZD NAME - 

T6 °— function j T OPERATOR -| 

L t FKT NAME -L is - new - ZUN -I- T OPERATOR -i 
L t FKT NAME - 

AUS ADA 11: PAKETERZEUGUNG 

O « (B.CII.AZ.I .G.F.A.ST.REC.Z) 

— paefcage - PAK NAME - is - new - ZUN - PAK NAME — AKT SCH ARG LISTE - pak * te * 

Name eines entsprechenden 
Schemas 


Erzeugung 
exneA la) 


■ AKT SCH ARG LISTE -i vnzedux 


AKT SCH ARG LISTE ■ 


Opexators 

Funktion 


Semantik: 

Der Name der erzeugten Programmeinheit wird eingeführt, an¬ 
schließend wird die Ausprägung des Schemas vorgenommen, in¬ 
dem die formalen durch die aktuellen Schemaargumente ersetzt 
werden (s. 6.3). Dadurch liegt nun eine normale Programmein- 
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heit vor, deren Verarbeitung wie beschrieben (1.2 oder 5.1) 
vorgenommen wird. 

Namen für globale Größen bezeichnen stets die Werte, die 
bei der SchemaVereinbarung oder Formulierung des Rumpfes 
angesprochen wurden, nicht die bei der Erzeugung angespro¬ 
chenen. 

(vgl. PASCAL: globale Größen einer Prozedur) 

Beispiel: Ausprägungen des Funktionsschemas horner 

procedure horneraufrufe is 

type complex j_s record re,im : float; end record ; 

type rpol 10 array (0 .. 10) of_ float; 

type rpol5 i_s array (integer ränge 0 .. 5) of float; 

type cpol 10 i_s array (0 .. 10) of complex; 

type cpol5 is array (0 .. 5) of complex; 

-- Koeffizientenfelder für reelle und komplexe Polynome 

-- 10. und 5. Grades. 

rl0 : rpol10; 

r5 : rpol5; 

cl0 : cpol10; 

c5 : cpol5; 

function "+" (a,b : complex) return complex is 
begin 

return (a.re + b.re, a.im + b.im); 
end "+"; 

function (a,b : complex) return complex is 
begin 

return (a.re*b.re-a.im*b.im,a.re*b.im+a.im*b.re); 
end ; 

— Jetzt sind alle verwendeten Operationen bekannt. 

-- Erzeugung verschiedener Funktionen 
-- aus dem Schema horner 
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function rhornerl0 i_s new horner (float,rpol 10); 

-- + und * als Standardvorbesetzung 
function rhorner5 i_s new horner (float,rpo!5,"+","*"); 

— + und * angegeben 

function chornerl0 is new horner (complex,cpol10); 

— + und * als Standardvorbesetzung 
function chorner5 is new horner (complex,cpo!5, 

komplexe_Arithmetik."+",kompl exe_Ari thmeti k.); 

— + und * aus Paket komplexe_Arithmetik; 
--Berechnung und Ausgabe der Werte. 


6,3 DAS ZUSAMMENSPIEL DER FORMALEN UND DER 
AKTUELLEN SCHEMAARGUMENTE 
Syntax: 

ADA 12: AKTUELLE SCHEMA ARGUMENT LISTE (AKT SCH ARG LISTE) 

O = {B,CH , AZ ,I,G,F,A,ST, REC ,Z ) » - {IF,0F,IOF,ITF,0TF} 


—rd> 


.o. 

- AKT SCHEMA ARG ■ 

.O. 


r VAR NAME 



AKT SCHEMA ARG 


Name dei foxmalen 
Schunaaxgumentei 




Aktuelle Sc.hemaaA.gujne.ntc 


in Reihenfolge dex foxmalen 
SchcmaoAgumente 


in beliebigex Reihenfolge 


ADA 13: AKTUELLES SCHEMA ARGUMENT (AKT SCHEMA ARG) 

f> « {B , CH , AZ , I ,G,F ,A,ST , RE C , Z ) » = { IF , OF , IOF. ITF ,0TF) 6 0 = {B.CH.AZ.I} 



Aktuellei Schemaoxgument füA: 
Eingabe {in) 

Ein-Au&gabe [in out ) 

Typ 

Pxozedux 

Funktion 
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Semantik: 

Ersetzung der Argumente der Reihenfolge nach und durch Anga¬ 
be des formalen Argumentnamens erfolgt nach den gleichen Re¬ 
geln wie Ersetzung der formalen durch die aktuellen Argumen¬ 
te bei Unterprogrammaufrufen. 

Die Ersetzung der Argumente für Eingabe von Werten erfolgt 
durch Kopieren des aktuellen Argumentes in das formale. Die¬ 
ses tritt innerhalb des erzeugten Paketes bzw. Unterprogram¬ 
mes wie eine Konstante auf. 

Bei einem Prozeß bezeichnen das formale und aktuelle Argu¬ 
ment den gleichen Prozeß. 

Ein aktuelles Argument für Ein/Ausgabe muß eine Variable 
(also keine Typkonversion) von einem Typ sein, für den die 
Zuweisung verfügbar ist. 

Aktuelle Argumente für Typen müssen folgende Kompatibili¬ 
tätsbedingungen erfüllen: 

- Ist das aktuelle Schemaargument für einen Typ ein abge¬ 
leiteter Typ, so wird verfahren, als ob der Basistyp, mit 
allen Einschränkungen des abgeleiteten Typs versehen, ak¬ 
tuelles Argument wäre. 

- Kompatibilität für skalare Typen ist nach Diagramm ADA 5 
geregelt. 

- Array Typen sind kompatibel, falls sie gleichen Komponen¬ 
tentyp, gleiche Anzahl von Indexbereichen und gleiche In¬ 
dextypen mit denselben Einschränkungen (evtl, keinen) be¬ 
sitzen. Sind dabei Komponenten- oder Indextyp formale. 
Schemaargumente, so werden diese vorher durch aktuelle 
ersetzt. 

- Zeigertypen sind kompatibel, falls sie den gleichen refe¬ 
rierten Typ aufweisen. 

- Für einen limitierten, geschützten Typ kann jeder Typ 
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(auch Prozeßtyp oder Filetyp) Libergeoen werden. 

Für einen geschützten Typ muß Zuweisung und Vergleich auf 
Gleichheit für den aktuellen Typ zur Verfügung stehen. 

Tritt eine formale Diskriminantenliste auf, so muß sie 
für formalen und aktuellen Typ identisch sein. 

Unterprogramme, die als aktuelle Schemaargumente überge¬ 
ben werden, müssen mit den formalen Unterprogrammen in 
Reihenfolge, Übergabeart und Typ (einschließlich Ein¬ 
schränkungen) der Argumente übereinstimmen, für Funktio¬ 
nen und Operatoren muß der Ergebnistyp übereinstimmen. An¬ 
wesenheit und Wert von Anfangswerten sind unerheblich 
(Das sind die gleichen Regeln wie bei der Umbenennung, 
siehe 2.8). 

Funktionen können als Operatoren übergeben werden und um¬ 
gekehrt. 
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B.6 Programmschemata 
6.4 BEISPIELE 

Beispiel 1: 

Paketschema für Matrix- und Vektorarithmetik: 

Als Schemaargumente werden übergeben: 

Komponententyp der Matrizen/Vektoren 
Nullelement des Komponententyps 

Additions- und Multiplikationsoperatoren für den Kompo¬ 
nententyp 

Für Vektoren und Matrizen mit dynamischem Indexbereich ste¬ 
hen dann folgende Operatoren und Funktionen zur Verfügung: 
(s eine Komponente; x,y Vektoren; a,b Matrizen) 


S * X 

Skalar • Vektor 

X + y 

Vektor + Vektor 

x * y 

Vektor • Vektor (Skalarprodukt) 

trans(a) 

Transponieren einer Matrix 

s * a 

Skalar • Matrix 

a + b 

Matrix + Matrix 

a * b 

Matrix • Matrix 


generic 

type komponente i_s private ; 
nullelement : komponente; 

with function "+"(x,y Komponente) return komponente 
is <>; 

with function "*"(x,yKomponente) return komponente 
is <>; 

package vektoren_und_matrizen_paket is 

type vektor is^ array (integer ränge <>) of_ komponente; 
type matrix i_s array (integer ränge <>,integer ränge <>) 
of_ komponente; 

function "*"(s:komponente;x:vektor) return vektor; 
function "+"(x,y:vektor) return vektor; 


function (x,y:vektor) return komponente; 
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function trans(a:matrix) return matrix; 
function "*"(s:komponente;a:matrix) return matrix; 
function "+"(a,b:matrix) return matrix; 
function "*"(a,b:matrix) return matrix; 
function "*"(a:matrix;x:vektor) return vektor; 
index_fehler,anschlusszahl_fehler : exception ; 
end vektoren_und_matrizen_paket; 

package body vektoren_und_matrizen_paket is 

function (s:komponente;x:vektor) return vektor is 
resultat : vektor(x'ränge); 
begin 

for index iji x'ränge 
loop 

resultat(index):= s * x(index); 
end loop ; 
return resultat; 
end 

function "+"(x,y:vektor) return vektor is^ 
resultat : vektor(x'ränge); 
begin 

for index vn_ x'range 
loop 

resultat(index):= x(index) + y(index); 
end loop ; 
return resultat; 
end "+"; 

function (x,y:vektor) return komponente is^ 
resultat : komponente := nullelement; 
begin 

for index i_n x'range 
loop 

resultat:= resultat + x(index) *y(index); 
end 1oop ; 
return resultat; 
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end ; 

function trans(a:matrix) re turn matrix is_ 
resultat : matrix(a'range(2),a'range(l)); 
begin 

for zeile i_n a'range(2) 
loop 

for spalte iji a'range(l) 
loop 

resultat(zeile,spalte):= a(spalte,zeile); 
end loop ; 
end loop ; 
re turn resultat; 
end trans; 

function "*'!(s: komponente;a: matrix) re turn matrix is^ 
resultat : matrix(a‘range(l),a'range(2)); 
begin 

for zeile i_n a'ränge(1) 
loop 

for spalte i_n a'range(2) 
loop 

resultat(zeile,spalte):= s * a(zeile,spalte); 
end loop ; 
end loop ; 
return resultat; 
end 

function "+"(a,b:matrix) return matrix i_s 
resultat : matrix(a 1 range(1),a'range(2)); 
begin 

for zeile jm a'ränge(1) 
loop 

for spalte i_n a'range(2) 
loop 

resultat(zeile,spalte):= a(zei le,spalte) + 

b(zeile,spalte); 

end loop ; 
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end loop ; 
re turn resultat; 
end 

function (a,b:matrix) return matrix i£ 
resultat : matrix(a'range(l),b'range(2)); 
prod_sum : komponente; 
begin 

for zeile i_n a'range(l) 
loop 

for spalte i_n b'range(2) 
loop 

prod_sum:= nullelement; 

for ink vn_ 0 .. a ' 1 ength(2)-1 

loop 

prod_sum:= prod_sum 

+a(zeile,a'first(2)+ink) 
*b(b'first(l)+ink,spal te); 

end loop ; 

resultat(zeile,spal te):= prod_sum; 
end loop ; 
end loop ; 
return resultat; 
end 

function (a:matrix;x:vektor) return vektor i_s 
resultat : vektor(a 1 range(1)); 
prod_sum : komponente; 
begin 

for index Jji a' ränge (1) 
loop 

prod_sum:= nullelement; 
for ink iji 0 .. x'length-l 
loop 

prod_sum:= prod_sum 

+a(index,a'first(2)+ink) 

*x(x'first+ink); 
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end loop ; 

resultat(index):= prod_sum; 
end loop ; 
return resultat; 
end 

end vektoren_und_matrizen_paket; 

Beispiel 2: 

Das Pakötschema schlangenpaket stellt dem Benutzer ein Warte 
Schlangenkonzept für einen beliebigen Datentyp zur Verfügung 
Aus einer Schlange werden die Elemente in der Reihenfolge 
ihrer Ankunft wieder ausgegeben (FIFO). laenge gibt die An¬ 
zahl, der Elemente in einer Schlange an. Der Versuch, einer 
leeren Schlange ein Element zu entnehmen, löst die Ausnahme 
schlange_leer aus (siehe 7.3). Intern wird eine Schlange 
durch den geschützten Typ schlangen_infos repräsentiert. Es 
wird das Paket zeiger_verwaltung benutzt (siehe 6.1, Bei¬ 
spiel 1). 

with zeiger_verwaltung; 
generi c 

type element is_ private ; 
package schlangenpaket is 

type schlangen_infos is_ pri vate ; 
schlange_leer : exception ; 

procedure push (schlänge : in out schlangen infos; 
elem : in element); 

procedure pop (schlänge : in out schlangen infos; 
elem : out element); 

function laenge (schlänge : in_ schlangen_infos) return 
integer; 

private 

package 1 isten_verwaltung is 

new zeiger Verwaltung (komponente => element); 
use 1isten_verwaltung; 
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type schlangen_infos is 
record 

first,last : zeiger_typ := nul 1 ; 
laenge : integer := 0; 
end record ; 
end Schlangenpaket; 

package body schlangenpaket is 
use listen_verwaltung; 

procedure push (schlänge : in out schlangen infos; 
elem : jm element) is 

begin 

if schlänge.last = nul 1 

then holen (schlänge.1ast); 

schlänge.last. al1 := (eiem, nul1 ); 
schlange.first:= schlänge.last; 
else holen (schlänge.last.nachfolger); 

schlange.1ast.nachfolger. all := (elem, nul1 ); 
schlange.1ast:= schlange.last.nachfolger; 

end if ; 

Schlange.1aenge:= schlänge.laenge + 1; 
end push; 

procedure pop (schlänge : in out schlangen_infos; 
elem : out element) is 

begin 

if schlänge.laenge = 0 then raise schlange_leer; 
end if ; 

elem:= schlänge.first.daten; 
aushaengen: 
declare 

hilfszeiger : zeiger_typ; 
begin 

hilfszeiger:= schlange.fi rst; 

Schlange.first:= schlänge.first.nachfolger; 
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ablegen (hi 1fszeiger); 
end aushaengen; 

schlange.1aenge:= schlänge.laenge - 1; 
if Schlange.laenge = 0 then schlänge.1ast:= nul1 ; 
end if ; 
end pop; 

function laenge (schlänge : vn schlangen_infos) return 
integer is 

begin 

return schlange.laenge; 
end laenge; 
end Schlangenpaket; 
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7. DIE BEHANDLUNG VON AUSNAHMEN 


Eine Ausnahme (exception) stellt bei der Ausführung eines 
Programmes eine Situation dar, in welcher die normale Ausfüh¬ 
rung des Programmes unmöglich wird. Dieser Fall kann eintre- 
ten aufgrund von Fehlern oder außergewöhnlichen Situationen 
während der Ausführung. Bei Eintreten einer speziellen Aus¬ 
nahme werden nachfolgende Aktionen des Programmes ausgelöst, 
die wir unter dem Begriff Ausnahmebehand¬ 
lung zusammenfassen. Verschiedene Standardfehlersituati¬ 
onen lösen automatisch bei Ausführung des Programmes vorde¬ 
finierte Ausnahmen aus, die zum Abbruch der Programmausfüh¬ 
rung führen (siehe 7.1). Diese Standardreaktionen werden nur 
dann ausgeführt, wenn vom Programmierer keine andere Behand¬ 
lung vorgeschrieben ist. 

Prinzipiell dienen drei Sprachelemente zur Ausnahmebehand¬ 
lung: 

- Durch eine entsprechende Vereinbarung wird der Name für 
eine Ausnahmesituation vereinbart. 

- Mit der raise -Anweisung wird die Behandlung einer Aus¬ 
nahme ausgelöst. 

- Im Ausnahmebehandlungsteil, der am Ende des Anweisungs¬ 
teils einer Programmeinheit steht, sind unter dem Namen 
der Ausnahme bzw. unter others die fehlerbehandelnden 
Aktionen festgelegt. 


7.1 VORDEFINIERTE AUSNAHMEN 

Die Ausnahmen constraint_error 

numeric_error 
select error 


13 Kaucher IV - ADA 
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storage_error 

tasking_error 

sind für jede Programmeinheit standardmäßig vordefiniert. 

Beim Auftreten einer entsprechenden Fehlersituation wird die 
Ausnahmebehandlung automatisch ausgelöst. Diese Fehlersitua¬ 
tionen werden zur Laufzeit des Programmes durch entsprechen¬ 
de (durch Pragmas unterdrückbare) Tests abgefragt und führen 
dann zum Programmabbruch. Die vordefinierten Ausnahmen kom¬ 
men also ohne Ausnahmevereinbarung, raise -Anweisung und Aus¬ 
nahmebehandlungsteil zur Wirkung. Dies schließt jedoch nicht 
die explizite Auslösung durch eine raise -Anweisung aus. Wei¬ 
ter kann die Zuordnung eines eigenen Ausnahmebehandlungsteils 
erfolgen oder die vordefinierte Ausnahme durch eine Ausnahme¬ 
vereinbarung überschrieben werden. 

Die vordefinierten Ausnahmen werden in folgenden Situationen 
ausgelöst. Dabei ist zu beachten, daß gewisse interne Kon¬ 
trollen zur Entdeckung von Fehlersituationen durch die Anga¬ 
be eines entsprechenden Pragmas innerhalb eines Blocks bzw. 
des Rumpfes eines Unterprogrammes, Paketes oder Prozesses 
unterdrückt werden können (siehe ADA 52 und 8.1): 


vordefinierte 

Ausnahme 

unterdrückba¬ 
rer interner 
Test 

Fehlersituation 

constraint error 

access check 

Versuch, über einen null- 



Verweis auf ein Objekt zu- 
zugreifen 


discriminant_ 

Versuch, eine nicht mit ei¬ 


check 

ner vorgegebenen Beschrän¬ 
kung verträgliche Diskrimi- 
nante zuzuweisen oder auf 
eine Komponente zuzugreifen, 
die für die gegenwärtige 
Diskriminante nicht exi¬ 
stiert 
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index check 

Versuch, mit den Indexwer¬ 
ten den zulässigen Indexbe¬ 
reich zu verlassen 


length check 

Versuch, eine unzulässige 
Länge von Feldern oder Teil - 
feldern zu benutzen 


ränge check 

Versuch, einen Wert zuzuwei¬ 
sen, der außerhalb des ge¬ 
forderten Wertebereichs 
liegt bzw. eine unverträg¬ 
liche Index-, Diskriminan¬ 
ten- oder Bereichsein¬ 
schränkung zu verwenden 

numeric error 

division check 

Bei Division oder Restbil¬ 
dung wird durch Null divi¬ 
diert 


overflow check 

Ergebnis einer numerischen 
Operation liegt außerhalb 
des zulässigen Wertebe¬ 
reichs 

storage error 

storage_check 

Bei Ausführung der Spei¬ 
cherbelegungsfunktion new 
würde der dafür vorgesehene 
Speicherplatz überschritten 
bzw. der Speicherplatz 
reicht nicht für den Prozeß 
oder die Programmeinheit 
aus 

select error 

— 

In einer select Anweisung 
sind alle Alternativen ge¬ 
schlossen und es existiert 
kein else-Teil 

tasking error 


Wird im rufenden Prozeß 
ausgelöst, falls der geru¬ 
fene Prozeß vor Annahme des 
Eingangsaufrufs terminiert 
oder bereits zur Zeit des 
Eingangsaufrufs terminiert 
hat 


13* 
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Hinweise: 

Die Pragmas zur Unterdrückung interner Tests sind lediglich 
als Empfehlung an den Compiler anzusehen und schließen nicht 
aus, daß dennoch eine entsprechende Ausnahme ausgelöst wird 
(z.B. durch Verbreitung aus einer gerufenen Einheit). Zu¬ 
dem ist die Unterdrückung solcher Tests erst dann anzuraten, 
wenn ein Programm ausreichend ausgetestet ist und zuverläs¬ 
sig arbeitet. 

Weitere Ausnahmen sind bei Benutzung der Standardpakete für 
die Ein- bzw. Ausgabe vordefiniert: 

status_error 

name_error 

device_error 

use_error 

data_error 

end_error 

1ayout_error 

Ihre Behandlung wird ausführlich in 11.1.3 besprochen. 


7.2 DIE VEREINBARUNG VON AUSNAHMEN 

Syntax: 

Aus 


ADA 18: VEREINBARUNG 

i.O- 


AUSNAHME NAME 


- exception 










7.3 Auslösen einer Ausnahme 
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Semantik: 

Der Name für eine bestimmte Ausnahmesituation wird einge¬ 
führt (etwa Singularität einer Matrix). Diese Ausnahme kann 
nun ausgelöst werden (7.3). Im Ausnahmebehandlungsteil 
(7.4) der vorliegenden (vereinbarenden) Programmeinheit oder 
des vorliegenden Blockes sollte eine Behandlung für diese 
Ausnahme angeführt sein. 

Beispiele: 

singulaer : exception ; 
iteration_divergent : exception ; 
ueberlauf, unterlauf : exception ; 

7.3 DAS AUSLÖSEN EINER AUSNAHME 

Die Auslösung einer Ausnahme und der damit verbundenen Aus¬ 
nahmebehandlung erfolgt explizit durch die Ausnahmeauslö¬ 
sung. 


Syntax: 


Aus 


ADA 23: ANWEISUNG (ANW) 


ZUN — AUSNAHME NAME 



H 


Semantik: 

Es wird die Identität der Ausnahme, falls ein Name angegeben 
ist, festgestellt und diese Ausnahme ausgelöst. Die Ausfüh¬ 
rung des Programmes wird dann mit dem zu dieser Ausnahme ge¬ 
hörigen Anweisungsteil im Ausnahmebehandl ungsteil fortge¬ 


setzt. 


Eine Ausnahme ohne Ausnahmename kann nur in einem Ausnahme- 
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behandlungsteil (jedoch nicht in einem geschachtelten Unter¬ 
programm, Paket oder Prozeß) auftreten. Sie löst erneut die¬ 
selbe Ausnahme aus, welche die Auslösung des Ausnahmebehand¬ 
lungsteils bewirkte. 

Beispiele: 

raise singulaer; 
raise ; 

raise iteration_divergent; 
raise pool(k) 1 fai1ure; 

raise constraint_error; -- explizite ausloesung 


-- einer vordefinierten ausnahme 


7,4 DER AUSNAHMEBEHANDLUNGSTEIL 

Im Ausnahmebehandlungsteil werden die Aktionen festgelegt, 
die beim Auftreten einer entsprechenden Ausnahme während der 
Ausführung des Programmes erfolgen sollen. 

Ein Ausnahmebehandlungsteil kann im Anweisungsteil 



end - 


eines Unterprogrammes (ADA 6), eines Paketrumpfes (ADA 9), 
eines Prozeßrumpfes (ADA 14) oder eines Blockes (ADA 24) 
(kurz E i n h e i t genannt) auftreten. 












7.4 Ausnahmebehandl ungstei 1 
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Behandlung von 


setbstde 4 uu.MXen Ausnahmen 


voideiiniexten Ausnahmen 


voxde^inierten Ausnahmen 
bei Bin/Ausgäbe 


allen restlichen Ausnahmen 


Der Ausnahmebehandlungstei1 einer Einheit behandelt in der 
Regel die mit Namen versehenen Ausnahmen, welche im Anwei¬ 
sungsteil der Einheit ausgelöst werden. Jede Ausnahme der 
Einheit darf höchstens einmal als Ausnahmeauswahl im Ausnah¬ 
mebehandlungsteil auftreten. Tritt in der Ausnahmeauswahl 
others auf, so werden hierunter alle vorher nicht namentlich 
genannten Ausnahmen behandelt einschließlich der Ausnahmen, 
die in der Einheit nicht sichtbar sind. 

Durch eine Ausnahmeauslösung bei Ausführung des Anweisungs¬ 
teiles der Einheit wird die Ausführung des zugehörigen 
Ausnahmebehandl ers , d.h. der auf die Acu>- 
nakmzauAwcLlil folgenden Anweisungsfolge bewirkt. Die natür¬ 
liche Ausführung des Anweisungsteils der Einheit wird dabei 
abgebrochen und die Ausführung der Einheit nach Ausführung 


Syntax: 

ADA 49: AUSNAHMEBEHANDLUNGSTEIL (AUSN BEHTL) 
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des Ausnahmebehandlers beendet. Insbesondere darf keine 
Sprunganweisung aus dem Ausnahmebehandlungsteil herausführen. 
Existiert für die ausgelöste Ausnahme kein Behandler (expli¬ 
zit oder durch others ), so wird die Ausführung der Einheit 
ebenfalls abgebrochen und eine Ausnahmebehandlung entspre¬ 
chend den Regeln in 7.5 durchgeführt. 

Der Ausnahmebehandlungsteil einer Einheit ist in jeder Be¬ 
ziehung (z.B. Blockstruktur) als Teil des Anweisungsteils 
dieser Einheit anzusehen. Es darf jedoch keine Sprunganwei¬ 
sung in diesen hineinführen. 


7,5 DIE VERBREITUNG VON AUSNAHMEN 

Das Auslösen einer Ausnahme bewirkt die Ausführung des zur 
Ausnahme gehörigen Behandlers. Bei der Zuordnung des Behand¬ 
lers ist zu berücksichtigen, in welchem Zusammenhang die 
Ausnahme ausgelöst wurde: 

(a) Die Auslösung während der Ausführung von Anweisungen be¬ 
wirkt die Ausführung des zugehörigen Behandlers (gekenn¬ 
zeichnet durch den Ausnahmenamen oder others ) im selben 
Anweisungsteil. 

Das Auslösen einer Ausnahme innerhalb eines Anweisungs¬ 
teils, der keinen Ausnahmebehandler für diese Ausnahme 
enthält, bewirkt eine Verbreitung der Aus¬ 
nahme gemäß den folgenden Regeln: 




7.5 Verbreitung von Ausnahmen 
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Ausnahme ausgelöst 
im Anweisungstei1 

bewirkt Abbruch 
der Ausführung 
bzw. Abarbeitung 

und Auslösung der¬ 
selben Ausnahme 

eines Unterpro¬ 
grammrumpfes 

des Unterpro¬ 
grammes 

in der rufenden 
Programmeinhei t an 
der Stelle des Un¬ 
terprogrammaufrufs 

speziell eines 
Hauptprogrammes 

des Hauptpro¬ 
grammes 

— 

eines Blockes 

des Blockes 

im Anweisungstei1, 
der den Block ent- 
häl t 

eines Paket¬ 
rumpfes (Biblio¬ 
thekseinheit) 

des Hauptpro¬ 
grammes 

— 

eines Paket¬ 
rumpfes (keine 

Bibiiotheksein- 
hei t) 

des Paket¬ 
rumpfes 

in der Einheit, de¬ 
ren Vereinbarungs¬ 
teil den Paket¬ 
rumpf (bzw. den 
Rumpfstumpf im Fall 
einer Untereinheit) 
enthält 

eines Prozeß¬ 
rumpfes 

des Prozesses 
und dessen Ter¬ 
minierung 

— 

eines Ausnahme- 
behandlers (jedoch 
nicht in einem un¬ 
tergeordneten 
Block) 

der gegenwärti¬ 
gen Einheit 

entsprechend obigen 
Regeln, falls die 
gegenwärtige Ein¬ 
heit einen Unter¬ 
programmrumpf , ei¬ 
nen Block oder ei¬ 
nen Paketrumpf dar- 
steil t. 
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Beispiel: 

procedure p i_s 

error : exception ; 
procedure r; 

procedure q is 
begin 
r; 

-- Nach Auslösen von error wird A 
-- durchgeführt 

exception 


when error => -- Ausnahmebehandler A 


end q; 

procedure r is 
begin 

-- Nach Auslösen von error wird 
— die Ausnahme nach q verbreitet 
-- und dann A durchgeführt 


end r; 
begin 


q; 


— Nach Auslösen von error wird B 

— durchgeführt 


exception 


when error => 


— Ausnahmebehandler B 
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(b) Bei Auslösung einer Ausnahme während der Abarbeitung des 
Vereinbarungsteiles eines Blockes oder Rumpfes oder der 
Abarbeitung einer Unterprogramm-, Paket- oder Prozeßver¬ 
einbarung wird diese Abarbeitung abgebrochen und die 
Ausnahme auf die Einheit verbreitet, welche die Abarbei¬ 
tung bewirkt hat: 


Ausnahme ausgelöst 
bei Abarbeitung 

bewirkt Abbruch 
der Abarbeitung 
bzw. Ausführung 

und Auslösung dersel¬ 
ben Ausnahme 

einer Unterpro¬ 
gramm-, Paket-, 
Prozeßspezifika¬ 
tion (keine Biblio¬ 
thekseinheit) 

der Unterpro¬ 
gramm-, Paket-, 
Prozeßspezifi ka- 
tion 

in der Einheit, wel¬ 
che die Spezifika¬ 
tion enthält 

einer Unterpro¬ 
gramm-, Paket-, 
Prozeßspezifika¬ 
tion (keine Bibi io- 
thekseinheit) 

des Programmes 

— 

des Vereinbarungs¬ 
teils eines Unter¬ 
programmrumpfes 
(kein Hauptpro¬ 
gramm) 

des Unterpro¬ 
grammes 

in der rufenden Pro¬ 
grammei nhei t 

des Vereinbarungs¬ 
teils eines Haupt¬ 
programmrumpfes 

des Programmes 

— 

des Vereinbarungs¬ 
teils eines 

Blockes 

des Blockes 

in der Einheit, de¬ 
ren Anweisungen den 
Block enthalten 
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des Vereinbarungs¬ 
teils eines Paket¬ 
rumpfes (keine 

Bibiiotheksein- 
heit) 

des Paketes 

in der Einheit, wel¬ 
che den Paketrumpf 
(bzw. den Rumpfstumpf 
im Fall einer Unter¬ 
einheit) enthält 

des Vereinbarungs¬ 
teils eines Paket¬ 
rumpfes (Biblio¬ 
thekseinheit) 

des Programmes 

— 

des Vereinbarungs¬ 
teils eines Pro¬ 
zeßrumpfes 

des Prozesses 

in der aktivierenden 
Einheit 


Beispiel: 
blockl: declare 

begin 

block2: declare 

n : integer := f(); 
begin 

exception 

when error => ... 
end block2; 

exception 

when error => ... 
end blockl; 

Wird die Ausnahme error während der Initialisierung von 
n durch Ausführung der Funktion f ausgelöst, so wird 
sie im Block blockl behandelt. 
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(c) Spezielle Regelungen werden notwendig für die Ausnahme¬ 
verbreitung bei der Prozeßkommunikation. So können z.B. 
durch die nicht vorhergesehene Terminierung kommunizie¬ 
render Prozesse Fehlersituationen auftreten. Eine typi¬ 
sche Fehlersituation vor einem beabsichtigten Rendez¬ 
vous liegt dann vor, wenn ein Prozeß P einen Eingang ei¬ 
nes anderen Prozesses Q aufruft und Q ist schon termi¬ 
niert. Diese Situation löst im rufenden Prozeß automa¬ 
tisch die vordefinierte Ausnahme tasking_error aus. 

Weitere Fehlersituationen sind während eines Rendez¬ 
vous' möglich: 

- Tritt bei Ausführung des Anweisungsteiles einer 
accept -Anweisung eine Ausnahme auf, die nicht lokal 
behandelt wird, so wird das Rendezvous abgebrochen 
und die Ausnahme an den rufenden Prozeß (an die Stelle 
des Eingangsaufrufs) sowie an den gerufenen Prozeß 
verbreitet. 

- Terminiert der gerufene Prozeß abnormal (etwa wegen 
einer abort-Anweisung), so wird die Ausnahme tasking_ 
error an der Stelle des Eingangsaufrufs im rufenden 
Prozeß ausgelöst. 

- Umgekehrt löst die abnormale Terminierung eines rufen¬ 
den Prozesses keine Ausnahme im gerufenen Prozeß aus. 
Ist das Rendezvous bereits begonnen, so wird es been¬ 
det und der gerufene Prozeß bleibt unberührt; andern¬ 
falls wird der Eingangsaufruf gelöscht. 

- Jeder Prozeß Q kann in einem anderen Prozeß P durch 
die Anweisung 

raise p'failure 

eine Ausnahme auslösen. Der die Ausnahme auslösende 
Prozeß Q bleibt unberührt, während für Prozeß P die 
Ausnahme failure eintritt. Wird P gerade ausgeführt, 
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so tritt p'failure an den derzeitigen Punkt der Aus¬ 
führung und wird nach den üblichen Regeln behandelt. 
Wartet P gerade, wird die Wartezeit sofort beendet 
und die Ausnahme behandelt. Hat P einen Eingang geru¬ 
fen, so wird dieser Aufruf gelöscht, falls das Rendez¬ 
vous noch nicht begonnen hat; anderenfalls wird zu¬ 
nächst das Rendezvous beendet (der gerufene Prozeß 
bleibt unberührt). 

Ein Ausnahmebehandler für die Ausnahme failure kann 
nur innerhalb des Prozesses P stehen. 


7,6 BEISPIEL 

Im folgenden Programm, welches 20 2><2-Matrizen einliest, 
invertiert und ausgibt, wird eine Ausnahme singulaer 
für den Fall behandelt, daß eine zu invertierende 
Matrix singulär ist. Bei Auslösung der Ausnahme singu¬ 
laer findet eine Verbreitung in die Prozedur p statt. 

Dort wird ein entsprechender Kommentar ausgegeben und 
die Ausführung von p beendet. Danach wird die Ausfüh¬ 
rung des Programmes in der for-Schleife der Prozedur matinv 
mit dem nächsten Wert i fortgesetzt. 

Zur Ein- und Ausgabe von Matrizen wird das Paket mat2_2_ea 
verwendet, das in 11.2.2.4 vereinbart wird. 

with mat2_2_ea; use mat2_2_ea; 
with text_io; use text_io; 
procedure matinv is 

type matrix is^ array (1 .. 2,1 .. 2) of f 1oat; 
singulaer : exception ; -- Ausnahme singulaer verein- 
-- bart 
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procedure invert (m : i_n out matrix) i_s 
det,a,b : float; 

epsilon : constant float := 1.0e-10; 
begin 

det:= m(l,l)*m(2,2)-m(l,2)*m(2,l); 
if abs(det) < epsilon then 

raise singulaer; end if ; -- Ausloesung von 

-- singulaer 

b:= 1.0/det; a:= m(l,l); m(l,l):= m(2,2)*b; 
m(2,2):= a*b; m(l,2):= -m(l,2)*b; 
m(2,l):= -m(2,l)*b; 
end ; 

procedure p is^ 
x : matrix; 
begin 

read(x); invert(x); print(x); 
exception 

when singulaer => put("Matrix ist singulaer"); 
when others => put("unerwarteter Fehler"); 
end ; 

begin 

for i i_n 1 .. 20 loop 

put("Iteration"); put(i); 
p; 

end loop ; 
end; 
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8. COMPILERINSTRUKTIONEN 


Während der Übersetzung eines Programmes treten Fragen auf, 
die nichts mit der Logik des Programmes zu tun haben, deren 
Beantwortung jedoch für den erfahrenen Programmierer inter¬ 
essant sein kann. Bei Kenntnis der Zielmaschine kann man zum 
Beispiel durch genaue Festlegung der Speicherplatzaufteilung 
für eine Variable eine Beschleunigung der Adressierung er¬ 
zielen. Wenn man von der Richtigkeit eines Programmes über¬ 
zeugt ist, kann man etwa auf eine Indexüberprüfung verzich¬ 
ten, um die Laufzeit des Programmes zu beschleunigen. 


8.1 DIREKTIVEN (PRAGMAS) 

Mit Hilfe einer Di r e k t i v e (eines P r a g m a s) 
werden dem Compiler gewisse Informationen über den Verlauf 
der Übersetzung gegeben. Zu den hier vorgestellten sprach- 
abhängigen Direktiven können noch weitere implementierungs¬ 
abhängige definiert werden. Eine Direktive, deren Namen der 
Compiler nicht kennt, hat keinen Einfluß auf die Wirkung 
des Programmes. 

Der syntaktische Aufbau aller Pragmas ist 

- pragma -NAME-AKT DIR ARG LISTE - 

cteA Wiaktsivz, Aktuzlte. An.gimQ,ntLUtz 
^ü/i dioAQ, V'LnalitLve, 

Im implementierungsabhängigen Paket System sind unter ande¬ 
rem Konstanten zusammengefaßt, die die Speicherplatzauftei¬ 
lung festlegen. Diese können umdefiniert werden. 



8.1 Pragmas 
Speicherolatzaufteilung: 
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Syntax: 

Aus 

ADA 52: PRAGMA 


- pragma 


—I— (memory_s 1 ze )-> 

I— (storage_un1 t) —I— (T )— 


I KONST -()> 

(kein Name) 


SpeÄcheA.platzbe.daA.t de A Einheit 
Anzahl den Biti je Speiche/ietnheit 


Semantik: 

Diese Pragmas stehen vor einer Bibliothekseinheit. 
memory_size legt den Speicherplatzbedarf der Bibliotheksein¬ 
heit in Speicherplatzeinheiten fest. storage_unit bestimmt 
die Anzahl der Bits pro Speichereinheit für diese Biblio¬ 
thekseinheit. Beide überschreiben die im Paket System ste¬ 
henden I Konstanten gleichen Namens. 

Festlegung der Objektmaschine: 

Syntax: 

Aus 

ADA 52: PRAGMA 

- pragma - pstem) -©- NAME -© - ObjtktmdUnt - Q - 


Semantik: 

Dieses Pragma steht vor einer Bibliothekseinheit. Es legt 
die Objektmaschine fest, mit der diese Bibliothekseinheit 
ausgeführt werden soll. Die AZ Konstante name des speziellen 
AZ Typs System.system_name wird dadurch überschrieben. 


14 Kaucher IV - ADA 
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Speicherverwaltung: 

Objekte vom referierten Typ eines Zeigertyps werden während 
der Laufzeit generiert und in den Speicher gelegt. Ist der 
vorhandene Speicherplatz belegt, so kann eine automatische 
Speicherfreigabe (garbage collection) gestartet werden, die 
den Speicherplatz von nicht mehr benötigten Objekten frei- 
gibt. Diese Freigabe kann durch ein Pragma verhindert wer¬ 
den. 

Syntax: 

ADA 52: PRAGMA 

- pragma fcontrolleQ -0- Z TYP NAME —Q Speichex^ 3 abc Q_ 


Semantik: 

Die automatische Speicherfreigabe für Objekte vom referier¬ 
ten Typ wird solange verhindert, bis die Gültigkeit des Zei¬ 
gertyps erlischt. Das Pragma steht im Vereinbarungsteil der 
Programmeinheit, in der der Zeigertyp vereinbart wurde, 
dort, wo auch eine Darstellungsangabe stehen kann. 

Aufruf von Unterprogrammen: 

Syntax: 

UnteA.ptog'ixume. werden bei Aufm4 in den 
Text kopiext. 


ADA 52: PRAGMA 


(i n H n e) — 


-gJ- 


-o- 

UPG NAME -Hj)- 


Semanti k: 

Die Rümpfe der aufgeführten Unterprogramme werden nach Er¬ 
setzung der formalen durch die aktuellen Argumente an der 
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Stelle ihres Aufrufes in den erzeugten Code kopiert. Ist der 
Unterprogrammname überladen, so wirkt das Pragma für alle 
Versionen. Das Pragma steht im gleichen Vereinbarungstei1 
wie die Unterprogramme. 

Die Wirkung eines Unterprogrammes wird durch das Pragma 
inline nicht verändert. 

Syntax: 


AUS ADA 52: PRAGMA 


- pragma —(Interface^ 


<I> 


PI LI 

- NAME -O- UPG NAHE « «*** sp-M^ Q— 

eötcA Pxog/uximiexiptadie 


Semantik: 

Das Unterprogramm PI ist in der angegebenen Programmier¬ 
sprache LI geschrieben. Das Pragma steht nach der ADA-Spezi- 
fikation dieses Unterprogrammes im gleichen Vereinbarungs¬ 
teil. Für das Unterprogramm darf kein Rumpf oder Rumpfstumpf 
folgen. Der Code des von einem Ll-Compiler übersetzten Un¬ 
terprogrammes PI steht* dem ADA-Compiler zur Verfügung. Die 
Aufrufkonventionen der Sprache LI sind zu beachten. 

Optimierung: 

Syntax: 

AUS ADA 52: PRAGMA 

^ ragnia C ° ptini< *t ) CD I CilnD I 1 OptünLime. leÄt- odtn SpeicheAplaXzbidaAi. 

L -(s^-Lqj -—-©- 


Semantik: 

Optimiere die Laufzeit bzw. den Speicherplatzbedarf der Pro- 


14 
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grammeinheit, in dessen Vereinbarungstei1 das Pragma auf- 
tritt. 


Syntax: 

Aus ADA 52: PRAGMA 


-0-T- A TYP NAME —, 

L REC TYP NAME -L@- 


SpeJ.cheApZaXzipaA.znde. AbipcicheAxtng 


<D- 


Semantik: 

Bei der Darstellung des angegebenen Typs soll möglichst we¬ 
nig Speicherplatz verwendet werden. Das Pragma steht dort, 
wo eine Darstellungsangabe für den Typ stehen kann. 

Programmtext: 


Syntax: 

AUS ADA 52: PRAGMA 


Wa»e eXnu TcitiiZe 



Semantik: 

Diese Pragmas können überall dort im Programm eingefügt wer¬ 
den, wo ein Semikolon steht, und vor der ersten Programmzei¬ 
le. 

include bewirkt, daß das angegebene Textfile an dieser Stel¬ 
le eingefügt wird. 

list on bedeutet, daß ab dieser Stelle der Programmtext vom 
Compiler aufgelistet werden soll, list off bedeutet, daß die 
Auflistung des Programmtextes beendet werden soll. 
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Priorität von Prozessen: 


Syntax: 


AUS ADA 52: PRAGMA 


- pragma — (pHorltyy 


-©— I AUSDR -0- 


legt P/Uoi-Ltät des Pxozesies ödes. des Hauptpxogiuumi best 


<ly 


vom voxdeiiniexten Typ pxioxity 


Semantik: 

Der statische Ausdruck vom Typ priority wird ausgewertet und 
dem Prozeß oder dem Hauptprogramm als Priorität zugewiesen 
(siehe 9.6). 

Das Pragma darf nur im äußersten Vereinbarungstei1 des Haupt¬ 
programmes oder in einer Prozeßspezifikation stehen. 

Unterdrücken von Tests: 


Syntax: 


Aus ADA 52: PRAGMA 

- pragma — {suppress") —(T)-j- (access_check) - 


Untexdxücke die 

folgenden 

Kontxolten: 


Ist Wext des 
Zeigexs null? 


■0- 

r- Z TYP NAME - 

- Z KONST NAME - 


- Z VAR NAME - 


-CD- 


~ (discr1m1nant_check^ -|-{Ty 


E 


Existiext Kom¬ 
ponente iüx diese 
Viskximinante? 


REC TYP NAME -i 
REC VAR NAME - 


<2> 


-^index_checlT)- 


O 


Index innexhnlb 
des BexeicJts? 


-p A TYP NAME- 

- A KONST NAME - 

- A VAR NAME - 


<!> 


-(l ength_checlT)— 


O 


Länge von Feldexn 
odex Teilen 
koxxekt? 


Tee 


D 


T TYP NAME 
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-("rangecheck)— 


Index- bzw. Vii- 
kniminantenein- 
ichaänkung zutäiiig? 


(storagecheck)— 


o- 


o- 


Reicht Speichel &ün 
Aua^ü/wung den 
Funktion neu) aui? 

- {division_check) — 


Diviiion duxch 0 ? 

-- (överf low_check") - Q 7)- 


übentaui? 


T6e 0 U{G,F,A,REC} 
~ : 


r TYP NAME - 

t VAR NAME - 


<D- 


faonmalei Argument on 


j- 1 TYP NAME - 

- Z VAR NAME - 

- Z KONST NAME - 


<>> 


Tell.G.FJ 


-T- T typ NAME- 

- T KONST NAME - 

- t VAR NAME - 


Semantik: 


<>> 


o- 


Das Pragma steht im Vereinbarungstei1 einer Einheit. Es be¬ 
wirkt, daß in dieser Programmeinheit der angegebene Test 
(siehe 7.1) ausgeschaltet wird, und zwar 

- für alle Elemente der in Frage kommenden Typen, falls kein 
Argument angegeben wurde 

- für alle Elemente eines Typs, falls ein Typname als Argu¬ 
ment angegeben wurde 

- für die angegebene Variable oder Konstante. 


Tritt die Ausnahme, deren Auslösen durch das Pragma gesperrt 
wurde, trotzdem auf, etwa durch Verbreitung (Weitergabe) 
aus aufgerufenen Einheiten, so ist die Wirkung des Program¬ 
mes unvorhersehbar. Das Pragma verhindert also nicht gene¬ 
rell das Auslösen der entsprechenden Ausnahme und sollte da¬ 
her nur verwendet werden, wenn die Ausnahme garantiert nicht 
ausgelöst wird. 


8.2 DARSTELLUNGSANRABEN 


Die physikalische Darstellung der Daten hat auf die Logik ei- 
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nes Programmes keine Wirkung, daher reicht im Normalfall eine 
vom Compiler gewählte Darstellung aus. (Unter der Dar¬ 
stellung einer Größe verstehen wir etwa die Spei¬ 
cherplatzaufteilung, die Adresse, die Reihenfolge der Kompo¬ 
nenten einer Record Variablen, die internen Werte für die 
Konstanten eines Aufzählungstyps). Zur Erhöhung der Effizi¬ 
enz oder zur Kommunikation mit anderen Programmen oder Gerä¬ 
ten kann es jedoch wichtig sein, die genaue Darstellung ei¬ 
ner Größe zu bestimmen. 


Syntax: 


ADA 50: DARSTELLUNGSANGABE (DARST ANG) 

e ■ (B.CII.AZ.l.G.F.A.ST.REC.Z) 


üi* - I AUSDR — 


-PZS NAME-1 

-Z TYP NAME — ILp— (storaqe_s<*e) - use — 1 AUSDR — 


Foffc.|nii.| J.-i .ivt- 

ipieelitiiJen 

I». Al>A 391 


SpetdtC'tbi'Xnä j 


- F TYP NAME 


*D— 


“I 


G AUSDR - | 
F AUSDR -J 


UmUodi i’iung ) 
de* inte*- l 
neu Vnut. f 
Ja AZ Tj/f« I 


for — AZ TYP NAME — «1 — A AGGREGAT 


Festlegung j 
de* Reco*d- > 
dutstetlungj 


-for - REC TYP NAME — UM - record - 


RECORD DARSTELLUNG 


record - 


L_ for -Ja T KONST NAME 

^2 t VAR NAME - 




— UPG NAME - 


— PAK NAME - 

— PZS NAME - 

— ENTRY NAME - 


Adresse da Rumpln yj.igs . „ 


Adresse eines lnte**u(>tei • u 


Semantik: 


L use — at — 1 EINF AUS 
West '• 


Eine Darstellungsangabe legt gewisse Details der physikali¬ 
schen Darstellung einer Größe fest und überschreibt die nor¬ 
malerweise vom Compiler gewählte Darstellung. Die Wirkung 
der Darstellungsangaben wird im einzelnen später beschrie- 
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ben. 

Eine Darstellungsangabe wirkt auf solche Größen, die im 
gleichen Vereinbarungstei1 vereinbart wurden. Für einen Typ 
können mehrere Darstellungsangaben nur dann gegeben werden, 
wenn sie verschiedene Eigenschaften beschreiben. Die Dar- 
stellungsangabe gilt für alle Größen eines Typs; will man 
unterschiedliche Darstellungen für verschiedene Variable 
desselben Typs, so muß man einen abgeleiteten Typ definieren. 
Es gibt keine Darstellungsangaben für abgeleitete Typen von 
Zeigertypen. Für abgeleitete Typen, die auch benutzerdefi¬ 
nierte Unterprogramme von ihren Basistypen übernehmen, sind 
nur Längenangaben gestattet. 


8,2.1 LÄNGENANGABEN 


Syntax: 

Aus 

use — I AUSDR ~— 

Bitanzahl X 


ADA 50: DARSTELLUNGSANGABE (DARST ANG) 

6 » (B,CH,AZ,I,G,F,A,ST,REC,Z) 
T69 


• for ■ 


■ t TYP NAME - 


Längenangabe 


Semantik: 

Der statische Ausdruck für die Bitanzahl X wird ausgewertet 
und dem Attribut size für den angegebenen Typ zugewiesen, 
size beschreibt die Anzahl der Bits, die zur Speicherung ei¬ 
ner Variablen des Typs T verwendet werden. X muß größer oder 
gleich der minimal notwendigen Bitanzahl sein. Eine Längen¬ 
angabe für einen strukturierten Typ wirkt nicht auf die Kom¬ 
ponenten, sondern höchstens auf die Lücken zwischen den Kom¬ 
ponenten. Eine Längenangabe für einen Typ mit dynamischen 
Eigenschaften, etwa unbeschränkter Indexbereich, ist nicht 






8.2.1 Längenangaben 


217 


erlaubt. 


Syntax: 

Aus 


ADA 50: DARSTELLUNGSANGABE (DARST ANG) 


■ for -PZS NAME -1 

I-Z TYP NAME -MiHj 


storage_s1ze)- use — 1 AUSDR — (T)— 

SpeJ.chcAbtdan.fi o 


Semantik: 

Der I Ausdruck für den Speicherbedarf o wird ausgewertet und 
dem Attribut storage_size für den angegebenen Z Typ oder 
Prozeß zugewiesen. storage_size beschreibt für einen Prozeß 
oder Prozeßtyp die Anzahl der Speichereinheiten, die zur Ak¬ 
tivierung des Prozesses verwendet werden, für einen Zeiger¬ 
typ die Anzahl der Speichereinheiten, die für alle im Ver¬ 
lauf des Programmes erzeugten Objekte des referierten Typs 
dieses Zeigertyps bereitgestellt werden. 

Syntax: 

Aus 

ADA 50: DARSTELLUNGSANGABE (DARST ANG) 

- for - F TYP NAME f 7 )— (actual_del ta) use -y G AUSDR —i 

L F AUSDR -J-©— 

Sch*JMMeJ.tt 6 


Semantik: 

Der reelle Ausdruck <5, der nur Literalkonstanten beinhalten 
darf, wird ausgewertet und dem Attribut actual_delta für den 
Festpunkttyp zugewiesen. actual_delta beschreibt die tat¬ 
sächlich für die Darstellung des Festpunkttyps verwendete 
Schrittweite. 6 muß kleiner oder gleich der in der Typver¬ 
einbarung gegebenen Schrittweite sein. 
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8.2,2 AUFZÄHLUNGSTYPDARSTELLUNG 


Syntax: 


Aus ADA 50: DARSTELLUNGSANGABE (DARST ANG) 

Au 6 zählungitypdaAA teltung 

-for — AZ TYP NAME — üü — A AGGREGAT —©— 


Semantik: 

Durch das Aggregat, dessen Komponenten typ integer und des¬ 
sen Indextyp der angegebene AZ Typ ist, werden die internen 
Werte für die AZ Konstanten festgelegt. Die integer Werte 
müssen der Ordnung des AZ Typs entsprechen. Die attribu- 
tierten Funktionen succ, pred und pos werden durch eine 
Darstellungsangabe in ihrer Wirkung nicht beeinflußt, sie 
gelten für den Typ, wie er vereinbart wurde. 


8,2.3 RECORDDARSTELLUNG 


Syntax: 


AUS ADA 50: DARSTELLUNGSANGABE (DARST ANG) 

-for - REC TYP NAME — use - record - RECORD DARSTELLUNG - end - record -0— 


ADA 51: RECORD DARSTELLUNG 


n 


t _ mod — I EINF AUS 

Mit v 


±n; 


KOMP NAME - Ü - I EINF AUS - £iüS£ - I EINF AUS -Q- I EINF AUS -Q^ 

Petition u {iut bit X (attbit p 
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Semantik: 

Alle integer Ausdrücke v, y, X und p sind statisch. Die An¬ 
fangsadresse des Records muß ein Vielfaches von v sein. 

Für jede angegebene Komponente werden die Attribute position 
auf y, first_bit auf X und last_bit auf p gesetzt. 

Innerhalb eines Records werden die relativen Positionen y 
der einzelnen Komponenten in Speichereinheiten angegeben. 

Die Numerierung beginnt bei 0. Die Positionen der tatsäch¬ 
lich belegten Bits werden relativ zum Beginn der Komponente 
bei 0 durch X (erstes Bit) und p (letztes Bit) beschrieben. 

Der angegebene Speicherbereich muß ausreichend groß sein. 

Nur für Komponenten oder Diskriminanten, die eine statische 
Einschränkung haben, dürfen Darstellungen angegeben werden. 

Darstellungsangaben für Komponenten mit dynamischen Eigen¬ 
schaften sind nicht erlaubt. 


8.2.4 ADRESSANGABEN 


Syntax: 

Aus 


ADA 50: DARSTELLUNGSANGABE (DARST ANG) 

Afkeßangabe 

_ for -pa r KONST NAME 
t VAR NAME - 
— UPG NAME — 

— PAK NAME — 

— PZS NAME — 

— ENTRY NAME - 


A dlUie du Rumpfianjangi • 


AcLiuie tinu lnte.iA.uptu 

l— use — at _ 1 EINF AUS 


WeAt 
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Semantik: 

Der statische Ausdruck a bestimmt 

- bei Variablen und Konstanten die Adresse 

- bei Unterprogrammen, Paketen oder Prozessen die Anfangs¬ 
adresse des Maschinencodes des Rumpfes 

- bei Eingängen eine Adresse, die einen Hardware-Interrupt 
beschreibt. 

Durch solche Adreßangaben dürfen keine Überlagerungen des 
Speichers (Overlays) hervorgerufen werden. 

Eine Hardware-Unterbrechung (Interrupt) darf nur mit höch¬ 
stens einem Eingang verbunden werden. Das Auftreten einer 
Unterbrechung wirkt wie ein Eingangsaufruf von einem Prozeß, 
dessen Priorität höher ist als die aller Benutzerprozesse 
(siehe 9.6). Die Behandlung von Unterbrechungen, z.B. das 
"Übertragung beendet" - Signal eines Druckers, kann so in 
ADA programmiert werden. 


8.3 UNKONTROLLIERTE SPEICHERFREIGABE 

Eine Ausprägung des Prozedurschemas unchecked_deallocation 
bietet die Möglichkeit, den durch Generierung einer Variab¬ 
len vom referierten Typ eines Zeigertyps belegten Speicher¬ 
platz ohne weitere Kontrollen wieder freizugeben. 

Syntax: 

Aus 

ADA 8: UNTERPROGRAMM ERZEUGUNG 

O - ( B,CH,AZ,I,G,F,A,ST,REC,Z] 

- procedure — PZD NAME - 1s - new - funcheckeddeal locati T TYP -(7)- Z TYP ~(T)~ 


'lefe'UeMeA. Typ T 
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Semantik: 

Es wird eine Prozedur p erzeugt, die eine Zeigervariable x 
als formales Ein/Ausgabeargument hat. Ein Aufruf der Prozedur 
p bewirkt, daß der Wert des aktuellen Argumentes x:= null ge¬ 
setzt wird. Die von x referierte Variable wird nicht mehr be¬ 
nötigt, und ihr Speicherplatz kann freigegeben werden. Falls 
eine weitere Zeigervariable auf die gleiche Variable verwies, 
so darf dieser Verweis jetzt nicht mehr benutzt werden. 


8,4 UNKONTROLLIERTE TYPUMWANDLUNG 

Der Wert eines jeden Typs wird durch ein Bitmuster darge¬ 
stellt. Das gleiche Bitmuster hat für verschiedene Typen 
auch verschiedene Bedeutung. Es kann für den Programmierer 
interessant sein, ein und dasselbe Bitmuster als Wert für 
verschiedene Typen zu interpretieren. 

Syntax: 

Aus 

ADA 8: UNTERPROGRAMM ERZEUGUNG 

O « (D.CH.AZ.I.G.F.A.ST.REC.Z) 

T9e — functlon — T FKT NAME — <s - new — (unchecked_conversioiQ -TP)—? T ( TYP T TYP -(T 


Semantik: 

Es wird eine Funktion f erzeugt, die ein formales Eingabe¬ 
argument x vom Typ Tj hat und deren Ergebnistyp T ist. 
und T haben die gleiche Darstellung. Durch einen Aufruf 
von f wird das Bitmuster, das das aktuelle Argument x re¬ 
präsentiert, als Wert des Typs T interpretiert. Tatsächlich 
findet also keine Aktion statt, das Bitmuster wird nur an¬ 
ders interpretiert. Das Funktionsergebnis muß stets ein de¬ 
finierter Wert vom Typ T sein. 
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9. HANDHABUNG VON PROZESSEN 


Pzioze^^e [£<uh 6) bilden neben Unterprogrammen und Paketen 
die dritte Form von Programmeinheiten. Sie ermöglichen die 
Entwicklung von Programmsystemen, deren Komponenten entweder 
gleichzeitig miteinander ablaufen müssen, oder zumindest so 
weitgehend unabhängig voneinander sind, daß bei einer ent¬ 
sprechenden sequentiellen Notation Programmstruktur und Lö¬ 
sungsidee kaum noch zu erkennen wären. Wenn hier nur weit¬ 
gehende, also nicht unbedingt vollständige Unabhängigkeit 
der Prozesse gefordert wird, dann deshalb, weil unter dem 
grundlegenden Begriff des Rendezvous' Möglichkeiten der Zu¬ 
sammenarbeit von und des Datenaustausches zwischen paralle¬ 
len Prozessen geboten werden. 

Prozesse besitzen jedoch nicht nur eine große Bedeutung für 
die Entwicklung und bessere Strukturierung von Programmsy¬ 
stemen, sondern sie bieten auch die Möglichkeit zur Erhöhung 
der Ausführungsgeschwindigkeit von solchen Programmsystemen. 
Moderne Großrechenanlagen (oder Rechnerverbunde) stellen 
nämlich in der Regel mehr als einen Zentralprozessor zur Ver 
fügung. Durch die Programmierung paralleler Prozesse können 
diese Prozessoren vom Programmierer zur parallelen und unab¬ 
hängigen Ausführung von Programmstücken veranlaßt werden, wo 
bei die Anzahl der zur Verfügung stehenden Prozessoren dem 
Programmierer nicht bekannt sein muß. 

Prozesse sind gemäß Diagramm ADA 1 keine selbständigen übeA- 
6e.£zungAeA.nheAXe.n (außer in der Form von Un£e.sie.inko,££e.n ); 
sie werden als Objekte eines Prozeßtyps im Vereinbarungstei1 
einer umfassenden Programmeinheit (eines Blocks, eines Unter 
programmes, eines Prozesses oder eines Bibliothekpaketes) 

- dem sogenannten Vorgänger - vereinbart oder dy¬ 
namisch durch Aufruf der Funktion new zu einem Zeiger mit 
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einem Prozeßtyp als referiertem Typ geschaffen. Die Ver¬ 
einbarung von Prozessen wird in Abschnitt 2.6 behandelt. Wir 
wiederholen hier die entsprechende 


Syntax: 


ADA 14: PROZESSRUMPF 


— ÜÜ-bod* T PZS TYP NAME 


T tYb I Yr NATIt ■] 

PZS VAR NAME 1 


PZS VAR NAME 1 1± ~r VEREINBTL 


-p VtKtlNBIL -i (*• 

I-L beqin -L [ 


I J exception j AUSN BEHTL —j 


PZS VAR NAME 
- PZS TYP NAME - 


ADA 15: PROZESSSPEZIFIKATION 


; T 


type - PZS TYP NAME - 
- PZS VAR NAME - 


- ENTRY VEREINB 


- DARST ANG - 


Pao zeßtyps pe z i iikation 
Pao z eÄ4 pe zX. fXkatio n 


• PZS TYP NAME 


- PZS VAR NAME - 


AufzälUung dc.l Eingänge 
dei PAOzeiiei 

Syntaktisch ist die Prozeßvereinbarung in eine Prozeßspezi¬ 
fikation und den dazugehörigen Prozeßrumpf unterteilt. 

Spezifikation und Rumpf eines Prozesses müssen im gleichen 
Vereinbarungsteil stehen. Eine Ausnahme von dieser Regel 
bilden Prozesse in Paketen: ihre Spezifikationen können be¬ 
reits außerhalb vom Vereinbarungstei1 des Paketrumpfes im 
sichtbaren oder geschützten Teil der Paketspezifikation ste¬ 
hen. 

Soll der Prozeßrumpf in Form einer Untereinheit getrennt 
übersetzt werden, muß er im Vereinbarungstei1 zunächst durch 
einen Stumpf ersetzt werden (ADA 17). 

Jeder Prozeß ist von einer Programmeinheit abhängig 
(dependent), und zwar von jener, in der der betreffende Pro- 
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zeß vereinbart ist, also von seinem Vorgänger. Von dieser 
Regel gibt es zwei Ausnahmen: 

(a) Wird der Prozeß selbst oder als Komponente eines Objekts 
durch eine Zeigervariable referiert, so ist er von jener 
Einheit abhängig, in der der entsprechende Zeigertyp 
vereinbart wurde. 

(b) Wäre der Prozeß nach obiger Regel und der ersten Ausnah¬ 
me von einem inneren Paket (also keinem Bibliothekspa¬ 
ket) abhängig, so gilt er als von jener Einheit abhän¬ 
gig, in der das innere Paket vereinbart wurde. 


9,1 DIE AKTIVIERUNG VON PROZESSEN 

Die Aktivierung eines Prozesses geschieht automatisch,und 
zwar grundsätzlich durch die Abarbeitung des Vereinbarungs¬ 
teils, der die Prozeßvereinbarung (möglicherweise auch als 
Komponente eines anderen Objektes) enthält. Vor Ausführung 
der ersten Anweisung des dem Vereinbarungstei1 nachfolgen¬ 
den Anweisungsteils sind also alle Prozesse des vorangehen¬ 
den Vereinbarungsteils aktiviert und werden nun parallel und 
unabhängig voneinander bis zu ihrer Terminierung (siehe 9.5) 
ausgeführt. Ist der Anweisungsteil des Vorgängers leer (et¬ 
wa bei einem Paketrumpf) oder fehlt der Rumpf total, so 
werden die Prozesse so aktiviert, als ob ein Rumpf mit ei¬ 
ner leeren Anweisung vorhanden wäre. 

Wird ein Prozeß dynamisch als referierte Variable oder Kom¬ 
ponente einer referierten Variable geschaffen, so wird er 
automatisch aktiviert und seine Ausführung begonnen. Der ent¬ 
sprechende Aufruf der Funktion new ist immer erst dann voll¬ 
ständig ausgeführt, wenn alle dabei neu geschaffenen Prozes¬ 
se aktiviert sind. 

Die Ausführung eines Prozesses ist beendet, wenn das Ende 
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der Anweisungen des Prozeßrumpfes erreicht ist, oder wenn er 
sich selbst terminiert oder von einem anderen Prozeß oder 
dem Vorgänger terminiert wird. Die Ausführung des Vorgängers 
ist beendet, wenn alle in ihm aktivierten Prozesse beendet 
sind (siehe 9.5). 

Beispiel: 

with textio; use text_io; 
procedure parallele_prozesse is 
task drucken; 
task body drucken is 
begin 

loop put("ada ist dufte"); 
new_line; 
delay 60.0; 
end loop ; 
end drucken; 
task zaehlen; 
task body zaehlen is^ 
i : integer; 
begin 

loop i:= 0; 

loop i:= i + 1; 

exit when i = 100; 
end loop ; 
end loop ; 
end zaehlen; 
begin 
nul 1 ; 
end ; 

Beim Eintritt in den Anweisungsteil der Prozedur sind die 
beiden Prozesse drucken und zaehlen aktiviert. Damit werden 
der Prozeduranweisungstei1 und die beiden Prozesse parallel 
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ausgeführt. Die Ausführung der Prozedur endet nicht vor der 
Terminierung der beiden Prozesse, d.h. im vorliegenden Fall 
nie. 

Hinweis : 

(1) Es ist nicht festgelegt, in welcher Reihenfolge die Pro¬ 
zesse eines Vereinbarungsteils aktiviert werden. 


9.2 DAS RENDEZVOUS VON PROZESSEN 

Entsprechend seiner Aufgabenstellung wird ein Prozeß gewisse 
Dienstleistungen für andere Prozesse anbieten bzw. Dienst¬ 
leistungen anderer Prozesse abrufen müssen; im ersten Fall 
beinhaltet der Prozeß passive Elemente und heißt daher passi¬ 
ver Prozeß oder slave-Prozeß, während er im zweiten Fall ak¬ 
tive Elemente enthält und daher aktiver Prozeß oder master- 
Prozeß heißt. Der Austausch, d.h. die Abgabe bzw. Annahme 
solcher Dienstleistungen zwischen zwei Prozessen geschieht 
während eines sogenannten Rendezvous ,zu dem die 
beiden Prozesse synchronisiert werden und während dem der 
Austausch von Daten möglich wird. 

Bevor wir auf Einzelheiten näher eingehen, wollen wir das 
Prinzip des Rendezvous' allgemeiner betrachten: 

(a) Ein passiver Prozeß stellt Dienstleistungen zur Verfü¬ 
gung. Jede dieser Dienstleistungen kann über einen Ein¬ 
gang des passiven Prozesses von einem beliebigen aktiven 
Prozeß angesprochen werden. Ein passiver Prozeß stellt 
seine Dienstleistungen gewissermaßen unkontrol1iert zur 
Verfügung. Jeder beliebige Prozeß, welcher einen ent¬ 
sprechenden Eingang aufruft, wird bedient. 

(b) Ein aktiver Prozeß hingegen muß den Namen des passiven 
Prozesses und den Namen des Eingangs, welchen er auf¬ 
ruft, wie auch die zu erwartende Dienstleistung kennen. 
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Treten während der Abarbeitung Fehler auf, so werden 
diese vom aufgerufenen Prozeß an den aufrufenden weiter¬ 
gegeben, aber nicht umgekehrt. 


9 , 2.1 DIE VEREINBARUNG EINES EINGANGS 


Wie schon erwähnt kann ein Prozeß Dienstleistungen zur Ver¬ 
fügung stellen, die über bestimmte Eingänge (entries) aufge¬ 
rufen werden können. Die Eingänge müssen in der Prozeßver¬ 
einbarung in folgender Form aufgeführt werden: 


Syntax: 


ADA 16: ENTRY VEREINBARUNG (ENTRY VEREINB) 

0 D - (B.CH.AZ.I) 

- entr* — ENTRY NAME ■ ' ' T63 ' 

Eingangsname 


INDEX BER -®-i 


VeAeÄnbanung 

eine* FamiLie. von indizieAXen Eingängen 
ecHC4 Eingangs 

FOR ARG LISTE -©— 


Semantik: 

Eine entry -Vereinbarung legt bei der Vereinbarung eines Pro¬ 
zeßtyps den Namen für einen Eingang bzw. - bei Angabe eines 
Indexbereiches - für eine ganze Familie (nämlich ein eindi¬ 
mensionales Feld) von verschiedenen Eingängen mit derselben 
formalen Argumentliste fest. 

Daher besitzen alle Prozesse eines Prozeßtyps Eingänge mit 
dem gleichen Namen, die von außerhalb dieser Prozesse mit 
dem Prozeßnamen als Zunamen und einer passenden aktuellen 
Argumentliste aufgerufen werden können (siehe 9.2.2). 

Eine Vereinbarung eines Eingangs entspricht völlig einer 
Prozedurvereinbarung. Die Verarbeitung der formalen Argu¬ 
mentliste verläuft entsprechend (siehe 5.1). 


15 * 
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Beispiele: 

1. task type roboter is 

entry taufe (wer_bin_ich : robbie_zeiger); 
entry lebenszeichen; 
end roboter; 

2. task boss is 

entry empfang(kontakt)(gespraech: geschaeft); 

entry lager_infos(nachricht: in String); 
end boss; 

3. task arbeitsVerwaltung is 

entry auftragsannahme(auftrag:datenblock); 
entry arbeitsvergabe(auftrag: out datenblock); 
end arbeitsverwaltung; 

Hinweise: 

(1) Diese Vereinbarung eines Eingangs lokalisiert noch nicht 
die Lage des Eingangs im Prozeßrumpf. Dies geschieht 
erst durch eine entsprechende accept-Anweisung (siehe 
9.2.3). 

(2) Ein Eingang kann in eine Prozedur umbenannt werden (sie¬ 
he 2.8). 

(3) Die einzelnen Eingänge einer Familie werden wie die Kom¬ 
ponenten eines eindimensionalen Feldes angesprochen. 

(4) Ein Eingangsname kann überladen werden, und zwar sowohl 
mit weiteren Eingängen als auch mit Prozeduren. 


9 . 2.2 DER AUFRUF EINES EINGANGS 

Ein Prozeß kann die Eingänge eines anderen Prozesses aufru¬ 
fen. 
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Syntax: Aus ADA 23: ANWEISUNG 


-ZUN — ENTRY 


—j— AKT ARG LISTE 


H 


Eingang&au6'tu& 


Semantik: 

Die Wirkung eines Eingangsaufrufs kann am besten im Zusammen¬ 
hang mit einer entsprechenden accept-Anweisung im gerufenen 

Prozeß beschrieben werden (siehe 9.2.4). Für den Eingangsauf¬ 
ruf sind folgende Punkte zu beachten: 

- Ein Eingangsaufruf darf nur in einem Prozeß oder im Vor¬ 
gänger des Prozesses auftreten, der den Eingang enthält. 

- Der Zuname muß immer den Namen des Prozesses enthalten, in 
dem der aufgerufene Eingang vereinbart wurde. 

- Die aktuelle Argumentliste muß zu der formalen Argumentli¬ 
ste der Entryvereinbarung passen, wie bei einem Prozedur¬ 
aufruf die aktuelle Argumentliste zu der formalen Argument¬ 
liste der Prozedurvereinbarung passen muß (vgl. 5.6). 

- Falls es sich um einen Eingang aus einer Familie handelt, 
wird zuerst der Indexausdruck ausgewertet, danach die ak¬ 
tuellen Argumente. 

Beispiele: 

arbeitsverwaltung.arbeitsvergabe(auftrag); 

boss.lager_infos("meldung"); 


9 . 2.3 DIE ANNAHMEANWEISUNG ( accept -ANWEISUNG) 

Die Aktionen, die beim Aufruf eines Eingangs durchgeführt 
werden sollen, stehen in einer accept- Anweisung im Rumpf des 
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Prozesses, in dem der Eingang vereinbart wurde. 
Syntax: 

ADA 26: ACCEPT ANWEISUNG 


— accept - ZUN - ENTRY - FOR ARG LISTE 


Eingang 


- do 



Aktionen wählend 
Rendezvous 


- ZUN — ENTRY NAME - 

- ZUN - ENTRY FAM NAME - 


Name 


bzw. Familienname 
des Eingangs 


ADA 64: ENTRY 

Oq * (D.CH.AZ.I) 

—|-ENTRY NAME- 

L ENTRY FAM NAME —^ T AUSDR 



Semantik: 

Die Wirkung der a£cept-Anweisung wird im Zusammenhang mit ei¬ 
nem entsprechenden Eingangsaufruf beschrieben (siehe 9.2.4). 

Es sind folgende Punkte zu beachten: 

(a) Eine accejrt- An Weisung darf nur im Rumpf des Prozesses 
stehen, in dem der Eingang vereinbart wurde. 

(b) Für einen Eingang können mehrere accept -Anweisungen vor¬ 
handen sein. 

(c) Die formale Argumentliste in der ACCEPT ANWEISUNG muß mit 
der in der zugehörigen ENTRY VEREINBARUNG Ubereinstimmen. 
Es gelten die gleichen Regeln wie bei einer Prozedur und 
einer separaten Prozedurspezifikation. 

Hinweise: 

(1) Jeder Prozeß kann nur accept-Anweisungen für seine eige¬ 
nen Eingänge enthalten. 

(2) Der Rumpf einer accept -Anweisung kann weitere accept- An- 
weisungen oder Eingangsaufrufe enthalten. 
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Beispiele: 

1. accept taufe(wer_bin_ich: robbie__zei ger) do 

eigene_person:= wer_bin_jich; 
end taufe; 

2. accept lager_infos(nachricht : vß string); 

3. a ccept arbeitsvergabe(auftrag : out datenblock) do 

auftrag:= aktueller_auftrag; 
end arbeitsvergabe; 


9 . 2.4 DIE SYNCHRONISIERUNG 

Die Synchronisierung von Prozessen erfolgt durch das Zusam¬ 
menspiel von Eingangsaufruf und accept -Anweisung in zwei ver¬ 
schiedenen Prozessen. Sie erfordert also grundsätzlich einen 
aktiven und einen passiven Prozeß. Der Ablauf der Synchroni¬ 
sierung geschieht in folgender Form: 

Die Ausführung eines Eingangsaufrufes in einem aktiven (ru¬ 
fenden) Prozeß hat zunächst die Wirkung, daß die Ausführung 
des Prozeßrumpfes ruht, bis in dem durch Eingangsaufruf be- 
zeichneten passiven (gerufenen) Prozeß eine accept -Anweisung 
für den gerufenen Eingang zur Ausführung gelangt. 

Gelangt umgekehrt ein passiver Prozeß an eine accept-Anwei¬ 
sung für einen Eingang, zu welchem noch kein Eingangsaufruf 
vorliegt, so wird die Ausführung des Prozedurrumpfes unter¬ 
brochen bis ein entsprechender Eingangsaufruf vorliegt. 

Dann erfolgt die Ersetzung der formalen durch die aktuellen 
Argumente wie bei einem Prozeduraufruf, und der Rumpf der 
accept -Anweisung wird ausgeführt. Während dieser Zeit blei¬ 
ben die beiden Prozesse zusammen und führen keine selbstän¬ 
digen Aktionen durch. Diesen Vorgang nennt man Ren de z- 


v o u s . 
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Nach Ausführung des Rumpfes der accept -Anweisung werden die 
Argumente wieder analog zum Prozeduraufruf behandelt. An¬ 
schließend setzen die beiden Prozesse ihre Verarbeitung mit 
der auf den Eingangsaufruf bzw. die accept -Anweisung folgen¬ 
den Anweisung wieder parallel und asynchron fort. 

Rufen mehrere Prozesse den gleichen Eingang eines passiven 
Prozesses auf, so werden sie in eine Warteschi a n- 
g e für diesen Eingang eingereiht. Beim Erreichen einer 
accept -Anweisung wird jeweils der erste Prozeß der Warte¬ 
schlange bedient. 

Die Einreihung in die Warteschlange erfolgt nach dem Prinzip 
"Wer zuerst kommt, mahlt zuerst" (first-in, first-out). 

Hinweise: 

(1) Man sollte im Rumpf einer accept -Anweisung nur diejeni¬ 
gen Aktionen beschreiben, die für die Synchronisation 
und den Datenaustausch zwischen den Prozessen unbedingt 
nötig sind. Denn zur Zeit des Rendezvous' findet ja kei¬ 
ne Paral leiarbeit statt. 

(2) Ein Eingang kann aufgerufen werden, bevor der entspre¬ 
chende Prozeß aktiviert wurde. 

(3) Ein Prozeß kann seine eigenen Eingänge aufrufen, doch 
führt dies in eine Sackgasse. 

(4) Es kann nicht Vorkommen, daß ein Prozeß in mehreren 
Warteschlangen steht. 


9,3 DAS BEDINGTE RENDEZVOUS 

Das bedingungslose Warten auf ein Rendezvous, wie es in der 
bisher besprochenen Form mit entry-Aufrufen und accept -An- 
weisungen programmiert wird, kann zu unerwünschten Situatio- 
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nen führen. Würde etwa ein Prozeß einen von mehreren Ein¬ 
gängen eines anderen Prozesses aufrufen, dieser jedoch zu¬ 
erst an eine accejDt-Anweisung für einen anderen als den auf¬ 
gerufenen Eingang gelangen, wären beide Prozesse - evtl, für 
immer - blockiert. Man denke z.B. daran, daß es sicher sinn¬ 
los ist, etwas auf einem Drucker ausgeben zu wollen, falls 
keiner am System angeschlossen ist, oder daß ein Bankkassie¬ 
rer unbedingt darauf wartet, einem Kunden etwas auszuzahlen, 
obwohl nur Kunden warten, die etwas einzahlen wollen. 

Daher ist eine - 1 aufzeitabhängige - Auswahl zwischen alter¬ 
nativen Anweisungen notwendig. 

Es gibt in ADA verschiedene Möglichkeiten, eine flexible 
Kommunikation zwischen Prozessen zu ermöglichen. Die ein¬ 
fachste ist das bedingte Rendezvous, bei welchem 
der aufrufende Prozeß einen bedingten Eingangsaufruf durch¬ 
führt. 

Syntax: Aus 

ADA 24: STRUKTURIERTE ANWEISUNG 

Bedingtet 

Etngangt-Au^tud 

— seiect - ZUN ENTRY r AKT ARG LISTE . ; 

__ I l -QAimj |.: 

Eingang sau $ tu- L eise -*- ANW : end - select - 


Semantik: 

Das Rendezvous über den aufgerufenen Eingang wird unmittel¬ 
bar ausgeführt, falls dies möglich ist, d.h. der gerufene 
Prozeß an einer entsprechenden accept -Anweisung wartet. An¬ 
dernfalls werden die auf eise folgenden Anweisungen ausge¬ 
führt. 
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Beispiel: 

select boss.lager_infos("meldung"); 
eise raeume auf end select; 


Auf der anderen Seite kann ein Prozeß gleichzeitig für mehr 
als einen Eingang ein Rendezvous anbieten: 

Syntax: Aus 

ADA 2A: STRUKTURIERTE ANWEISUNG 

kUvuuitLve. 

Annahme- 
anmhung 


— select 


when - B AUSDR -0i 
-L ACCEPT ANW 


or 



Bedingung 


Mte-toative 



end - select 


Semantik: 

Es werden zunächst alle in der Anweisung den Alternativen 
vorausgehenden Bedingungen ausgewertet. Eine Alternative 
heißt o f f e n , falls ihr keine Bedingung vorangeht oder 
diese Bedingung wahr ist, andernfalls heißt die Alternative 
g e s p e r r t . Sind alle Alternativen gesperrt, so werden 
die Anweisungen des else- Zweiges ausgeführt, falls dieser 
vorhanden ist. Fehlt der else- Zweig, so wird die Ausnahme 
select_error ausgelöst. 

Andernfalls wird aus allen offenen Alternativen eine Alter¬ 
native ausgewählt, für welche ein Eingangsaufruf vorliegt. 
Kann keine der offenen Alternativen ausgewählt werden, so 
werden die Anweisungen des else -Zweiges ausgeführt. Fehlt 
der else-Zweig, so wird auf einen passenden Eingangsaufruf 


gewartet. 
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Beispiel: 
select 

vvhen clock().second j_n besuchszeit => 
a ccept empfang(persoenlich) 

(gespraech : J_n geschaeftspartner) do 
notizzettel:= gespraech; 
formular_ausfuellen(notizzettel,formular); 
arbeitsverwaltung.auftragsannahme(formular); 
end empfang; 

or accept empfang(telefonisch) 

(gespraech : vn geschaeftspartner) do 
notizzettel:= gespraech; 
end empfang; 

formular_ausfuellen(notizzettel,formular); 
arbeitsverwaltung.auftragsannahme(formular); 
eise null ; 
end select ; 

Hinweise: 

Können mehrere Alternativen ausgewählt werden, so ist nicht 
festgelegt, welche ausgewählt wird. Diese Auswahl ist rein 
zufällig und i.a. nicht reproduzierbar. Es ist jedoch si¬ 
chergestellt, daß nur eine Alternative ausgewählt wird. Man 
kann also durch eine solche select-Anweisung sichersteilen, 
daß zwei Eingänge nie gleichzeitig ausgeführt werden. 


9.4 DAS VERZÖGERTE RENDEZVOUS 

Beim bedingten Rendezvous wurde ein Eingangsaufruf entweder 
sofort durchgeführt oder überhaupt nicht, wobei im gerufenen 
Prozeß mehrere Eingangsmöglichkeiten zur Verfügung gestellt 
werden können. Das verzögerte Rendezvous gibt nun 
auch die Möglichkeit, eine bestimmte Wartezeit bis zu einer 
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möglichen Synchronisierung vorzuschreiben. Für die Angabe 
dieser Wartezeit oder sogenannten [/eAzögeAungAzexX werden 
Werte des vordefinierten Festpunkttyps duration gemäß der 
Typdefinition 

type duration is delta 0.1 ränge -86400.0 .. 86400.0; 

verwendet. Werte dieses Typs geben jeweils die Verzögerungs¬ 
zeit in Sekunden (höchstens einen Tag) an. Nichtpositive 
Verzögerungszeiten haben keine Wirkung. 

Syntax: Aus 


ADA 24: STRUKTURIERTE ANWEISUNG 

Ve\iöge>Ue\ 

Eingangs - Au i*u{ 


— select - ZUN ENTRY T AKT ARG LISTE -i 

I-L0| ANW 


Eingangiaufiiwi 


L 


ir-deU* - F EI NF AUS -0- ANW -j 


izögcAungszeU 

Sekunden 


'1 

—1-end-select- 


Vea zogwtuigi anweis ung 


Semantik: 

Der Ausdruck für die VeAzogeAungAzexX, der vom vordefinier¬ 
ten Festkommatyp duration ist, wird ausgewertet. Ist der Ein¬ 
gangsaufruf innerhalb der Verzögerungszeit (in sec.) möglich, 
so wird er durchgeführt. Andernfalls wird die Anweisungsfol- 
qe hinter der Verzögerungsanweisung ausgeführt. 


Beispiel: 

select netzteil .aufladen; 
or delay 300.0; -- 5 min. Chance 

end select; 


Eine VeAzögeAungAaw)bUung kann in einem Prozeß auch iso¬ 
liert auftreten: 





















9.4 Verzögertes Rendezvous 


237 


Syntax: Aus 


ADA 23: ANWEISUNG (ANW) 


Ve/iz 5g eAung 4 aiweÄA ung 


dela* - F EINF AUS 


VeAzögznmgizeAst 


Semantik: 

Der Ausdruck für die Verzögerungszeit wird ausgewertet und 
der Prozeß für die Verzögerungszeit (in sec.) in den Warte¬ 
zustand versetzt. 

Im aufgerufenen Prozeß kann innerhalb einer alternativen 
accept- Anweisung auch eine Verzögerungsanweisung als Alter¬ 
native auftreten. Dann darf allerdings kein eise-Zweig vor¬ 
gesehen sein, und mindestens eine Alternative muß mit einer 
accept -Anweisung beginnen. 

Syntax: Aus 

ADA 24: STRUKTURIERTE ANWEISUNG 


alte-Muitivz accept -Amt’eütm.q 


when - ß AUSDR -0i 


AfPFPT AMU 


“ ALLtr1 ANW 

1.j 

- deU* F EINF AUS- 

-0- ANW j 


\LtcAna.tiviz I minder te»ti 
e.-üie accept -Anwe/tiung) 


Semantik: 

Zur Bestimmung der offenen Alternativen werden alle Bedin¬ 
gungen ausgewertet. Dabei wird für eine offene Alternative 
mit einer Verzögerungsanweisung unmittelbar nach Auswertung 
der Bedingung auch der Ausdruck für die Verzögerungszeit 
ausgewertet. Falls das entsprechende Rendezvous möglich ist. 
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wird eine offene Alternative mit einer accept -Anweisung aus¬ 
gewählt. Nach Durchführung des Rendezvous' und der nachfol¬ 
genden Anweisungen ist die Ausführung der alternativen 
accept -Anweisung beendet. 

Kann innerhalb der kürzesten Verzögerungszeit aller offenen 
Alternativen kein Rendezvous durchgeführt werden, so werden 
die Anweisungen hinter der zugehörigen Verzögerungsanwei¬ 
sung durchgeführt. (Haben zwei Alternativen die gleiche Ver¬ 
zögerungszeit, so ist nicht festgelegt, welche gewählt wird.) 
Damit ist die Ausführung der alternativen accept -Anweisung 
beendet. 

Beispiel: 
s elect 

when clock().second j_n besuchszeit => 
accept empfang(persoenlich) 

(gespraech : jm geschaeftspartner) do 
notizzettel:= gespraech; 
formular_ausfuel1en(notizzettel ,formular); 
arbeitsverwaltung.auftragsannahme(formular); 
end empfang; 

or accept empfang(telefonisch) 

(gespraech : j_n geschaeftspartner) do 
notizzettel:= gespraech; 
end empfang; 

formular_ausfuellen(notizzettel ,formular); 
arbeitsverwaltung.auftragsannahme(formular); 
or accept lager_infos(nachricht : i_n string); 
or de!ay 900.0; 
end select ; 

Hinweise: 

(1) Es ist nicht sinnvoll, mehrere Alternativen für Verzöge- 
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rungsanweisungen mit äquivalenten Bedingungen zu verse¬ 
hen, da immer nur die Verzögerungsanweisung mit der kür¬ 
zesten Verzögerungszeit zum Tragen kommt. 

(2) Die Auswahl offener Alternativen für ein Rendezvous ist 
maschinenabhängig. Programme, die hier auf einen spezi¬ 
ellen Auswahlmechanismus aufbauen, sind fehlerhaft. Es 
sind also folgende Situationen zu vermeiden: 

- Eine alternative accept-Anweisung besitzt mehr als ei¬ 
ne offene Alternative für einen aufgerufenen Eingang. 

- Es wurden verschiedene Eingänge eines Prozesses aufge- 
rufen, und eine accept-Anweisung besitzt offene Alter¬ 
nativen für diese Eingänge. 


9,5 DIE TERMINIERUNG VON PROZESSEN 

Die Ausführung eines Prozesses oder des Vorgängers eines 
Prozesses ist erst dann beendet, wenn die Ausführung des zu¬ 
gehörigen Rumpfes beendet ist und alle von ihm abhängigen 
Prozesse beendet (t e r m i n i e r t) sind. Entsprechend 
der Aufgabenstellung für Prozesse wird im Regelfall bei der 
Ausführung des Prozeßrumpfes das Ende des Anweisungsteils 
nicht erreicht werden. Daher ist für die normale Terminie¬ 
rung auch eine spezielle termi_nate-Anweisung vorgesehen. 

Beispielsweise betrachten wir einen Prozeß tt, von dem keine 
weiteren Prozesse abhängen, d.h. in dessen Vereinbarungsteil 
keine weiteren Prozesse vereinbart sind. 7r sei ein passiver 
Prozeß, der eine Reihe von Dienstleistungen über entsprechen 
de Eingänge anbietet. Die zugehörigen accept-AnWeisungen sei 
en in einer unendlichen Schleife realisiert, so daß das Ende 
des Prozeßrumpfes von tt nie erreicht wird. Für seine Termi¬ 
nierung muß dem Prozeß tt bekannt sein, daß keiner seiner Ein 
gänge mehr aufgerufen wird. Spätestens, wenn alle Prozesse, 
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die tt aufrufen, und dessen Vorgänger auf ihre Terminierung 
warten, muß auch tt terminiert werden. Dies geschieht mit ei¬ 
ner terminate -AIternative innerhalb einer alternativen 
accept-Anweisung. Denn während der Abarbeitung einer einfa¬ 
chen accept-An Weisung ist es sicher nicht sinnvoll, ir zu be¬ 
enden, während zwischen zwei accept-Anweisungen gar nicht 
festgestellt werden kann, ob noch ein Eingangsaufruf an tt 
erfolgen wird. 

Syntax: Aus 

ADA 24: STRUKTURIERTE ANWEISUNG 


BzcLinqte. T&uninieAuitg 


when - ß AUSDR -(»>)- 


AfPFPT AMU 

or • ■ 


- terminate - 

-©1 

L ANW ■ 

i 


itle.cX.-HUztoauU.\>i 


Semantik: 

Die Wahl einer terminate- AI ternati ve bewirkt die normale 
Terminierung eines Prozesses. Sie kann nicht in einem inne¬ 
ren Block stehen, welcher Prozesse vereinbart. 

Eine offene terminate -AIternative kann nur gewählt werden, 
falls der Prozeß, in dem sie auftritt, zur Menge der von ei¬ 
nem Block, Unterprogramm oder Prozeß abhängigen Prozesse ge¬ 
hört, und 

- entweder das Ende dieses Blockes, des Unterprogrammrumpfes 
oder Prozeßrumpfes erreicht ist 

- oder im Falle der Abhängigkeit von einem Prozeß eine ter ¬ 
mi nate- AIternative im Prozeßrumpf erreicht ist. 

Weiter kann diese terminate -AIternati ve nur dann gewählt 


werden, wenn alle anderen Prozesse dieser Menge, wie auch 
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jeder davon abhängige Prozeß (und so weiter) entweder termi¬ 
niert ist oder an einer alternativen accept- Anweisung mit 
einer terminate -Alternative wartet. 

Beispiele: 

1. seiect 

accept lebenszeichen; 
or terminate ; 
end select ; 

2. select 

accept aufladen(ladezeit : duration := 2160.0) do 
delay ladezeit; 
end aufladen; 
or terminate ; 
end select ; 

Neben der normalen Terminierung eines Prozesses durch Aus¬ 
wahl einer terminate -Alternative oder durch Erreichen des 
Rumpfendes kann ein Prozeß auch von einem anderen Prozeß aus 
(sozusagen gewaltsam) abgebrochen werden. Man spricht dann 
von einer abnormalen Terminierung. 

Syntax: Aus 

ADA 23: ANWEISUNG (ANW) 

abnowUe 

Te-’unou.euwg 



-abort -1— ZUN -PZS NAME 


Semantik: 

Die aufgelisteten Prozesse werden terminiert, ebenso alle 
abhängigen Prozesse. Weiter werden alle Prozesse abnormal 
terminiert, die von Unterprogrammen abhängen, welche von den 
terminierten Prozessen direkt oder indirekt aufgerufen wer- 


16 Kaucher IV - ADA 
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den. Ein abnormal terminierter Prozeß wird aus der Warte¬ 
schlange für die von ihm gerufenen Eingänge ausgereiht; be¬ 
findet er sich gerade in einem Rendezvous, wird der rufende 
Prozeß terminiert, während der gerufene Prozeß das Rendez¬ 
vous normal durchführt. Falls noch (möglicherweise verzöger¬ 
te) Eingangsaufrufe für einen abnormal terminierten Prozeß 
anstehen, so wird die Ausnahme taskingjerror für jeden ru¬ 
fenden Prozeß ausgelöst (einschließlich für den Prozeß, der 
sich gerade im Rendezvous mit diesem befindet) ohne Berück¬ 
sichtigung einer eventuell vorgesehenen Verzögerungszeit. 

Beispiel: 
exception 

when akkujeer => abort boss; 

Hinweise: 

(1) Die abnormale Terminierung eines Prozesses sollte nur 
in extremen Fehlersituationen vorgenommen werden. In den 
meisten Fällen wird das Auslösen der Ausnahme failure 
für den betroffenen Prozeß ausreichen, wodurch dort feh¬ 
lerbehandelnde Maßnahmen ermöglicht werden. 

(2) Ein Prozeß kann jeden beliebigen Prozeß, auch sich 
selbst, abnormal terminieren. 


9,6 PRIORITÄTSREGELUNG 

Ein Programm kann, unabhängig von der Anzahl tatsächlich zur 
Verfügung stehender Prozessoren, eine beliebige Anzahl von 
parallelen Prozessen enthalten. Bei der Ausführung des Pro¬ 
grammes kann dies, falls die Anzahl der Prozessoren nicht 
ausreicht oder überhaupt nur ein Prozessor zur Verfügung 
steht, die sequentielle Ausführung paralleler Prozesse zur 
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Folge haben. Da solche Prozesse verschiedene Dringlichkeit 
haben können, ist es für den Programmierer wichtig, diese 
selbst festzulegen. 

Syntax: Aus 

ADA 52: PRAGMA 

_ praqma _ (prlorTty) _ Q— | AUSDR Q W PxioMXÄt du Pnozu aea ode a du Hauptpu,gnwmu jut Q 

Atudmck von voidefötieAXem Typ p’Uoxlty 


Semantik: 

Die Direktive priority kann in einer Prozeßspezifikation 
oder im Vereinbarungsteil eines Hauptprogrammes stehen. Sie 
bewirkt zur Übersetzungszeit die Zuordnung der durch den 
I AUSDRUCK bestimmten Priorität an den zugehörigen Prozeß¬ 
typ bzw. an das Hauptprogramm. 

Der vordefinierte Typ priority ist ein implementierungsab¬ 
hängiger Untertyp von integer. Größere Werte dieses Typs 
bedeuten höhere Priorität. 

Prioritäten kommen dann zur Wirkung, wenn mehr parallele 
Prozesse zur Ausführung anstehen, als tatsächlich Prozes¬ 
soren momentan zur Verfügung stehen. In diesem Fall kann 
bei zwei Prozessen verschiedener Priorität nicht der Fall 
eintreten, daß der Prozeß mit niederer Priorität ausgeführt 
wird, während der Prozeß mit höherer Priorität nicht ausge¬ 
führt wird. 

Bei Prozessen mit gleichen Prioritäten ist eine Ausfüh¬ 
rungsreihenfolge nicht festgelegt, während bei Prozessen 
ohne explizite Prioritätszuordnung überhaupt keine Regeln 
außer für die Zeit eines Rendezvous' festgelegt sind: 

Befinden sich zwei Prozesse in einem Rendezvous, so wird 
das Rendezvous mit der höheren der den Prozessen zugeordne- 


16* 
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ten Prioritäten ausgefiihrt. Haben beide Prozesse keine zu¬ 
geordnete Priorität, dann ist auch für das Rendezvous keine 
Priorität definiert. 

Hinweise: 

Prioritäten sollten nur verwendet werden, um relative 
Dringlichkeiten von Prozessen entscheidend zu beeinflussen. 


9.7 GEMEINSAME VARIABLE 

Die Kommunikation zwischen Prozessen läuft in der Regel 
über ein entsprechendes Rendezvous ab. Daneben besteht na¬ 
türlich auch die Möglichkeit der Verwendung derselben glo¬ 
balen Variablen in verschiedenen Prozessen. Dabei entsteht 
aber die Schwierigkeit, daß ein Prozeß nur zu Zeiten der 
Synchronisierung mit einem anderen Prozeß genaue Kenntnis 
darüber hat, ob dieser momentan auf eine gemeinsame Daten¬ 
menge zugreift oder nicht. Dabei sind Beginn und Ende eines 
gemeinsamen Rendzvous' Synchronisierungszeitpunkte für zwei 
Prozesse und der Zeitpunkt der Aktivierung eines Prozesses 
Synchronisierungszeitpunkt mit dem aktivierenden Prozeß. 
Werden also gemeinsame Variable benutzt, so trägt der Pro¬ 
grammierer die Verantwortung dafür, daß eine gemeinsame Va¬ 
riable nicht gleichzeitig von mehr als einem Prozeß benutzt 
oder verändert wird. 

Darüberhinaus ist die Realisierung gemeinsamer Variablen 
durch die Sprache nicht festgelegt. Es ist also durchaus 
möglich, daß im konkreten Fall für jeden Prozeß Kopien von 
globalen Variablen angelegt werden und die globale Variable 
nicht immer auf dem entsprechenden Stand wie diese Kopie 
gehalten wird. Will man erreichen, daß eine gemeinsame Va¬ 
riable tatsächlich auf ihren neuesten Wert gebracht wird. 
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ist für diese Variable eine spezielle Prozedur aufzurufen, 
welche man als Ausprägung des Standardprozedurschemas 
shared_variable_update erhält. 

generic type shared is^ 1 imited private ; 
procedure shared_variable_update (x: in out shared); 

Aus diesem Schema wird mit dem Typ der Variable eine Proze 
dur erzeugt, die jedesmal dann aufzurufen ist, wenn eine 
Veränderung der gemeinsamen Variablen vorgenommen wurde. 
Nur durch den Aufruf dieser Prozedur ist sichergestellt, 
daß die Änderung auch wirksam wird. 

Syntax: Aus 

ADA 8: UNTERPROGRAMM ERZEUGUNG 

- procedure — PZD NAME ii - new — ^shared_var1ab1e_update) —(T) T69u * r TYP - 


Semantik: 

Als Ausprägung erhält man eine Prozedur, durch deren Auf¬ 
ruf man eine für mehrere Prozesse gemeinsame Variable auf 
ihren neuesten Wert bringt. 

Hinweise: 

Das Prozedurschema shared_variable_update ist nicht im Pa¬ 
ket Standard vereinbart, sondern bildet eine eigene Bibi io 
thekseinheit. Deshalb muß es durch eine Kontextangabe be¬ 
kannt gemacht werden. 


9.8 ATTRIBUTE 

Folgende Attribute sind für einen Prozeßtyp bzw. Prozeß de 
finiert: 
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Marne des 
Attributs 

Typ des 
Attributs 

Wert 

terminated 

boolean 

falsch, nach Vereinbarung bzw. 
Allocation des Prozesses, 
wahr, nach seiner Terminierung 

priority 

priority 

Priorität des Prozesses bzw. Pro¬ 
zeßtyps, falls diese definiert 
wurde (andernfalls darf das Attri¬ 
but nicht benutzt werden) 

storage size 

universal 
integer 

Speicherplatzbedarf für den Prozeß 
bzw. den durch den Prozeßtyp fest¬ 
gelegten Prozeß in Speichereinhei¬ 
ten 


Folgendes Attribut für die Eingänge eines Prozesses kann 
innerhalb des zugehörigen Prozeßrumpfes verwendet werden: 


Name des 
Attributs 

Typ des 
Attributs 

Wert 

count 

integer 

Anzahl der auf diesen Eingang 
wartenden Prozesse 
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9.9 BEISPIEL * > 

Die Programmeinheit grosshandel simuliert einen vereinfachten 
Handelsbetrieb, der aus den folgenden 3 Abteilungen besteht: 

- Chefabteilung (nimmt Aufträge entgegen, bzw. gibt Bestel¬ 

lungen auf - repräsentiert also die Firma gegenüber Ge¬ 
schäftspartnern) 

- Organisation (speichert die Aufträge/Bestellungen ab und 

verteilt die anfallende Arbeit je nach Dringlichkeit 
oder anderen firmeninternen Prioritäten) 

(nicht zu verwechseln mit dem Paket Organisation) 

- Versand (führt die Lagerverwaltung durch, d.h. speichert 

ankommende Waren ab und bedient die Kunden mit den ge¬ 
wünschten Waren) 

Diese 3 Abteilungen arbeiten voneinander unabhängig (paral¬ 
lel) und werden demgemäß durch Prozesse realisiert: 

Prozeß boss verkörpert die Chefabteilung, 

Prozeß arbeitsverwaltung die Organisation (benutzt dabei 
das Schemapaket schlangenpaket) 
und die Prozesse vom Prozeßtyp roboter verkörpern die La¬ 
gerarbeiter, also den Versand. 

Der Typ roboter taucht dabei nur als Recordkomponente auf. 
Der Lagerarbeiter wird also eigentlich durch den Typ rob- 
bie verkörpert, in dem noch allgemein zugänglich seine 
persönlichen Daten abgespeichert werden. Bei seiner 'tau¬ 
fe' bekommt er selbst einen lokalen Zeiger auf sich 
selbst zugewiesen, so daß auch ihm diese persönlichen Da¬ 
ten bekannt werden. 

Programmablauf: 

Der grosshandel startet zu Beginn durch Aktivierung der Pro¬ 
zesse boss, arbei tsverwal tung und bert.job, ernie.job, fred- 

Dieses Beispiel wurde als Seminararbeit von den Herren 
cand. math. M. Hanke und T. Rössel verfaßt. 
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job. Während der boss sich gleich in die Arbeit stürzt und 
die arbeitsverwaltung auf Aufträge wartet (selective wart), 
werden die 3 Lagerarbeiter erst getauft, bevor sie richtig 
arbeiten (Aufruf des Eingangs taufe). Der boss empfängt erst 
Briefe und dann Besucher oder Telefonanrufe und gibt Bestel¬ 
lungen auf oder nimmt sie entgegen (nachts übernimmt diese 
Arbeit ein Anrufbeantworter). Die Bestellungen bzw. ihre 
Auswirkungen auf den Versand werden der arbeitsverwaltung 
weitergegeben, die diese Informationen abspeichert (in der 
kartei). 

Die Lagerarbei ter rufen ihrerseits die arbei tsverwal tung auf, 
wenn sie den letzten Befehl ausgeführt haben, um neue Befeh¬ 
le zu erhalten. 

zusätzliche Einrichtungen: 

Prozeß netzteil: Da die roboter bei ihrer Arbeit Strom ver¬ 
brauchen, müssen sie sich gelegentlich wieder aufladen 
(am netztei1). 

Sollten sie vor lauter Arbeit nicht zum Aufladen kommen, 
sondern 'ausbrennen', können sie kurz vor dem 'Tod' noch 
die Firma in die Luft sprengen ( exception akkuleer). 

Prozeßtyp druckknopf: Um auch eine evtl. Terminierung zu er¬ 
möglichen (finanz. Bankrott, etc.) muß eine Vorrichtung 
existieren, daß die anderen Prozesse wissen, wann der 
boss terminiert. Dafür wurde der Prozeßtyp druckknopf in¬ 
stalliert, der regelmäßig benutzt wird, um einem Kollegen 
mitzuteilen: "Ich arbeite noch". Sollte also der boss 
terminieren, erfolgt kein solches Signal mehr bei dem 
Vorarbeiter bert, also wartet bert auf ein Lebenszeichen 
bis zum Programmende und analog die anderen Lagerarbei¬ 
ter, bis schließlich der ganze grossbetrieb terminiert. 
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package calendar is 
type time j_s 

record year : integer ränge 1901 .. 2099; 
month : integer ränge 1 .. 12; 
day : integer ränge 1 .. 31; 
second : duration; 
end record ; 

function clock return time; 

function "+"(a:time;b:duration) return time; 
function "+"(a:duration;b:time) return time; 
function "-"(a:time;b:duration) return time; 
function (a:time;b:time) return duration; 
end calendar; 

generic 

type elem j_s private ; 

package schlangenpaket is 

type schlangeninfo i_s private ; 
procedure push(schlange: vn out schlangeninfo;e: vn 
elem); 

procedure pop(schlange: in out schlangeninfo;e: out 
elem); 

function laenge(schlange: iji schlangeninfo) return 
integer; 

private 

type listenelem; 

type listenzeiger i_s access listenelem; 
type 1istenelem is 

record datenkomponente : elem; 

next : 1istenzeiger; 
end record ; 
type schlangeninfo i_s 
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record first,last : 1istenzeiger:= nul 1 ; 
laenge : integer:= 0; 

end record ; 
end Schlangenpaket; 

package body schlangenpaket is 

procedure push(schlange: i_n out schlangeninfo;e: in 
elem) is 

begin 

if schlänge.Iast= nul1 

then schlänge.last:= new 1istenelem(e, nu11 ); 

schlänge.first:= schlänge.last; 
eise schlänge.last.next:= new listenelem(e, nu!1 ); 
Schlange.last:= schlange.last.next; 

end if ; 

Schlange.laenge:= schlänge.laenge + 1; 
end push; 

procedure pop(schlange: in_ out schlangeninfo;e: out 
elem) is 

begin 

e:= Schlange.first.datenkomponente; 

Schlange.first:= schlänge.first.next; 

Schlange.laenge:= schlänge.laenge - 1; 

-- Das tatsaechliche Programm muesste dafuer sor 

— gen, dass die ueberfluessigen Listenelemente 
-- in einer Pointerhalde abgelegt werden, um 

— spaeter neu verwendet werden zu koennen. 

— Sonst wuerde das Programm bei einer gut flo- 
-- rierenden Firma mit Sicherheit im Chaos enden 
end pop; 

function laenge(schlange: vn schlangeninfo) return 
integer is 

begin 

return schlänge.laenge; 


end laenge; 
end schlangenpaket; 
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with calendar, schlangenpaket; 
package Organisation is 
use calendar; 

subtype besuchszeit js^ duration ränge 36000.0 .. 57600.0; 
— 10 - 16 Uhr 

frueher_morgen : constant duration := 28800.0; -- 8 Uhr 
feierabend : constant duration := 64800.0; -- 18 Uhr 

type richtung j_s (eingang,ausgang); 
type geldbetrag is delta 0.01 ränge 0.00 .. 999_999.99; 
type geschaeft is 

record name : string(l .. 20); 

Warenbezeichnung : natural; 
warenrichtung : richtung; 
preis_pro_einheit : geldbetrag; 
menge : natural; 
end record ; 

type auftragstyp j_s (1ieferungen,bestel1ungen); 
type datenblock i_s record 

-- Firmeninterne Warenbeschreibung 
typ : auftragstyp; 
end record ; 

package kartei is new Schlangenpaket (element => 

datenblock); 

use kartei; 

akku_kapazitaet : constant integer := 100; 
subtype ladung j_s integer ränge 0 .. akku_kapazitaet; 
existenzminimum : constant ladung := 15; 
energieschub : constant ladung := 5; 
end Organisation; 

with Organisation; 
procedure grosshandel is 


use Organisation; 
type robbie; 
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type robbie_zeiger is^ access robbie; 
task type roboter is 

entry taufe(wer bin ich : robbie_zeiger); 
entry lebenszeichen; 
end roboter; 

type robbie is record tag_der_anschaffung : time := 
clock(); 

kollege : robbie_zeiger := nul1 ; 
job : roboter; 
end record ; 

bert,ernie,fred : constant robbie_zeiger := new robbie; 
task boss is 

entry empfang(kontakt)(gespraech: vn geschaeft); 
entry lager_infos(nachrieht: j_n String); 
end boss; 

task arbeitsVerwaltung is 

entry auftragsannahme(auftrag:j_n datenblock); 
entry arbeitsvergabe(auftrag: out datenblock); 
end arbeitsverwaltung; 
task netzteil is 

entry aufladen(ladezeit: duration := 2160.0); 
end netzteil; 
task type druckknopf is 

entry infos(wen_soll_ich_rufen: robbie_zei ger); 
end druckknopf; 

type ruf j_s access druckknopf; 
task body arbei tsverwal tung is_ 

news,aktueller_auftrag : datenblock; 
aktueller_auftrag_vorhanden : boolean := false; 
warteschlange : array (auftragstyp) of schlangeninfos; 
begin 
loop 
select 

accept auftragsannahme(auftrag: i_n 

datenblock) do 
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news:= auftrag; 
end auftragsannahme; 
if not aktuel ler_auftrag_vorhanden 
then aktueller_auftrag:= news ; 

aktuel 1 er_auftrag_vorhanden:= true; 
else push(warteschlange(news.typ),news); 
end if ; 

or when aktueller_auftrag_vorhanden => 
accept arbeitsvergabe(auftrag: out 

datenblock) do 
auftrag:= aktueller_auftrag; 
end arbeitsvergäbe; 

if laenge(warteschlange(lieferungen)) = 0 
and laenge(warteschlange(bestel1ungen)) 

= 0 

then aktueller_auftrag_vorhanden:= false; 
eise null ; 

— hier wird aktueller_auftrag mit Hilfe 
-- der Prozedur pop (aus kartei) - abhaen- 
-- gig von firmeninternen Prioritaeten - 
-- mit dem jeweils ersten Auftrag aus der 
-- Besteilungs- bzw. Lieferungsschlange 
-- belegt. 
end if ; 
or terminate ; 
end select ; 
end loop ; 

end arbeitsverwaltung; 
task body netzteil is 
begin 
loop 

select accept aufladen(ladezeit: duration := 
2160.0) do 
delay ladezeit; 
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end aufladen; 
or terminate ; 
end select ; 
end loop ; 
end netzteil; 
task body druckknopf is 

arbeiter : robbie_zeiger := nul1 ; 
begin 

accept infos(wen_soll_ich_rufen: robbie_zei ger) do 
arbeiter: = wen_soll_ich_rufen; 
end infos; 

if arbeiter /= null then arbeiter.job.lebensZeichen; 
end ff ; 

end druckknopf; 
task body roboter 

aktuelle_ladung : ladung := akku_kapazitaet; 

akkujeer : exception ; 

eigene_person : robbie_zeiger := null ; 

Signal : ruf := null ; 
auftrag : datenblock; 
begin 

accept taufe(wer_bin_ich: robbie_zeiger) do 
ei gene_person:= wer_bin_ich; 
end taufe; 

Signal:= new druckknopf; Signal.infos( null ); 

lebenslauf: 

loop 

select arbeitsverwaltung.arbeitsvergäbe 

(auftrag); 

-- Robbie versucht, den Auftrag auszufüh- 
-- ren. Wenn etwas nicht machbar ist (Wa- 
— renmangel, Warenueberschuss etc.), er- 
-- folgt ein verzoegerter Aufruf von 
-- boss.lager_infos("Meldüng"). Sinkt 
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-- Robbies Akku-Ladung waehrend der Arbeit 
-- auf Null ab, wird die Ausnahme akkujeer 
-- ausgeloest. 

if aktuelle_ladung < existenzminimum 
then select netzteil.aufladen; 

or delay 300.0; — 5 min. Chance 

end select ; 
end if ; 

eise if aktuelle_ladung < akku_kapazitaet 

-- Energieschub 
then select netztei1.auf1aden; 

or delay 60.0; -- 1 min. Chance 

end select ; 
end if ; 
end select ; 

select accept lebenszeichen; 
or terminate ; 
end select ; 

if si gnal.all 1 terminated 
then Signal := new druckknopf; 

Signal.infos(eigene_person.kollege); 
end if ; 

end loop lebenslauf; 
exception 

when akkujeer => abort boss; 

-- Robbie bez. Energiereserven 
-- ausgeblutet. Unerbittliche 
-- Bestrafung des Chefs. 

end roboter; 
task body boss _i_s 

notizzettel,cassette : geschaeft; 

Signal : ruf := nul1 ; 

Vorarbeiter : robbie_zeiger := bert; 
formular : datenblock; 
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bankrott,reich_genug : boolean := false; 
procedure formular_ausfuellen 

(notiz: ji_n geschaeft; formular: mrt 
datenblock) is 

begin 

nul1 ; — Gespraech zu firmeninternen Daten auf- 

-- bereiten. 

end formular_ausfuellen; 
begin 

Signal:= new druckknopf; 

Signal.infos( nul1 ); 

tagesablauf: 

loop 

post_durchsehen: whi 1e empfang(schriftl ich)'count 

> 0 

loop 

accept empfang(schriftlich) 

(gespraech: i_n geschaeft) do 
notizzettel:= gespraech; 

— Je nach Lage der Kontoauszuege kann 
— hier bankrott bzw. reich_genug auf true 
-- gesetzt werden. 
end empfang; 

formular_ausfuellen(notizzettel ,formular); 
arbeitsverwaltung.auftragsannahme(formular); 
end loop post_durchsehen; 
tagsueber: 
loop 

if Signal .all 'terminated 
then Signal:= new druckknopf; 

Signal.infos(vorarbei ter); 
end if ; 
select 

when clock() .second iji besuchszeit => 
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accept empfang(persoenlich) 

(gespraech: jji geschaeftspartner) 
do 

notizzettel:= gespraech; 
formular_ausfuel 1 en(notizzettel, 
formul ar); 

arbeitsverwaltung.auftragsannahme( 
formular); 

end empfang; 

or accept empfang(telefonisch) 

(gespraech: vn geschaeftspartner) do 
notizzettel:= gespraech; 
end empfang; 

formular_ausfuellen(notizzettel,formular); 
arbeitsverwaltung.auftragsannahme 

(formular); 

or accept 1 ager_infos(nachricht: rn_ string); 
-- In Abhaengigkeit von der Nachricht Ware 
-- bestellen oder abbestellen, bei Ueber- 

— lastung des Lagers weitere Roboter an- 
-- schaffen. 

or delay 900.0; — boss guckt alle 15 min. 

— auf die Uhr! Mit Sekretaerin flirten, 

— den klugen Kopf hinter der dazugehoe- 
-- rigen Zeitung verschwinden lassen, oder 

— alles, was Maennern Spass macht, lesen. 
end select ; 

exit when clock().second >= feierabend; 
end loop tagsueber; 
nachts: 

loop — Anrufbeantworter tut das Noetigste 
if Signal.all 1 terminated 
then Signal:= new druckknopf; 

signal.infos(vorarbei ter); 
end if ; 


17 Kaucher IV - ADA 
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select 

accept empfang(telefonisch) 

(gespraech: vn geschaeft) do 
cassette:= gespraech; 
end empfang; 

formular_ausfuellen(cassette,formular); 
arbei tsverwal tung.auftragsannahme( fornular); 
eise nul 1 ; -- busy looping around 
end select ; 

exit when clock().second -- Wenn Chef kommt, 

— +- 5 min. 

in frueher morgen-300.0 .. frueher_morgen+ 
300.0; 
end loop nachts; 

exit when bankrott or reich_genug; 
end loop tagesablauf; 

— Jetzt hat's ein Ende mit der Schufterei! 
end boss; 

begin -- Ab hier arbeitet der grosshandel, also 
— boss, arbeitsverwaltung und die roboter. 
bert.kollege:= ernie; 
bert.job.taufe(bert); 
ernie.kollege:= fred; 
ernie.job.taufe(ernie); 
fred.job.taufe(fred); 
end grosshandel; 
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10. PROGRAMMSTRUKTUR UND MODULARITÄT 


Mit ihren vielfältigen Möglichkeiten zur Programmstrukturie¬ 
rung erfüllt die Programmiersprache ADA weitestgehend die 
heutigen Wünsche des Softwareengineering. Insbesondere die 
Aufspaltung eines Programmes in verschiedene Übersetzungs¬ 
einheiten mit den zugehörigen Gültigkeitsregelungen für Ver¬ 
einbarungen ermöglicht einerseits die gezielte Entwicklung 
großer Programmpakete (etwa in top-down-Methode), anderer¬ 
seits auch die Erstellung von Bibliotheken zunächst unabhän¬ 
giger, allgemein brauchbarer Routinen, welche zu einem spä¬ 
teren Zeitpunkt erst zu größeren Programmen zusammengefaßt 
werden (bottom-up-Methode). 


10.1 DIE PROGRAMMBIBLIOTHEK 

Ein Programm besteht aus einer oder mehreren übeAÄetzixng^exn- 
keÄXzn, die gemeinsam oder getrennt übersetzt werden. Die 
Übersetzungseinheiten eines Programmes gehören zu einer 
Programmbibi iothek. Jede Übersetzungsein¬ 
heit, die nicht Uyit 2 Aalvih(uX einer anderen ist, heißt 
Bibliothekseinheit. 


17* 
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KONTEXTANGABE • 


vollständige 
Liste de 1 
Übersetzungs¬ 
einheiten 


Biblio¬ 

theks¬ 

einheit 


Unter¬ 

einheit 


- UNTERPROGRAMM SCHEMA SPEZIFIKATION - 

■ PAKET SCHEMA SPEZIFIKATION - 

- UNTERPROGRAMM - 


- UNTERPROGRAMM SPEZIFIKATION ■ 

- UNTERPROGRAMM ERZEUGUNG - 

- PAKET RUMPF - 

- PAKET SPEZIFIKATION - 

- PAKET ERZEUGUNG - 


L separate -0“ ZUN — PGE NAME 


enthält zugeJiö- 
rigen Rumpfstumpf 


- UNTERPROGRAMM - 

- PAKET RUMPF - 

- PROZESS RUMPF 


Zur Identifikation müssen innerhalb einer Programmbibiiothek 
die Namen aller Bibliothekseinheiten verschieden sein; dies 


gilt natürlich nicht für den zu einer entsprechenden Spezi¬ 
fikation gehörigen Rumpf, die beide denselben Namen führen 
müssen. Der Name eines getrennt übersetzten Unterprogrammes 
darf kein Operatorsymbol sein; eine getrennt übersetzte Funk¬ 
tion kann aber in einen Operator umbenannt werden. 


Ein Unterprogramm, ein Paketrumpf oder ein Prozeßrumpf, in¬ 
nerhalb einer übergeordneten Einheit vereinbart, kann als ei¬ 
ne UntQAQyinkoÄX definiert und somit getrennt von ihrer über¬ 
geordneten Einheit übersetzt werden. In diesem Fall wird in 
der übergeordneten Einheit an Stelle des Unterprogramm-, Pa¬ 
ket- oder Prozeßrumpfes lediglich ein entsprechender Rumpfi- 
Atumpfi vereinbart: 

Aus ADA 17: 


Rumpfs tumpf 

-p UNTERPROGRAMM SPEZIFIKATION 

— packaqe—body — PAK NAME 

- task-body — PZS NAME 


!—©- 
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Die zugehörige Untereinheit, welche den vollständigen Rumpf 
enthält (einschließlich der Spezifikation bei einem Unter¬ 
programm), erwähnt nach dem Wortsymbol separate den Namen 
der Programmeinheit, in welcher der zugehörige Rumpfstumpf 
steht. 

Ist diese Programmeinheit selbst eine Untereinheit, so muß 
ihr Name zusammen mit dem Namen ihrer Obereinheit angegeben 
werden, usw. In diesem Fall ist also die Verwendung eines 
sogenannten Zunamens für die Programmeinheit notwendig, der 
die Namen aller übergeordneten Einheiten bis zur ersten Bib¬ 
liothekseinheit umfaßt (vgl. ADA 58 und 10.3,10.4,10.5). 

Die Namen aller Untereinheiten einer Bibliothekseinheit und 
die Namen aller Untereinheiten dieser Einheiten, usw. müssen 
verschieden sein. 

Bezüglich der Gültigkeit und Sichtbarkeit von Größen (siehe 
10.2,10.3) wird eine Untereinheit so gehandhabt, als stünde 
sie tatsächlich an der Stelle des zugehörigen Rumpfstumpfes. 

Beispiel: 

In dem Paket Studienordnung 

with Student; 
package Studienordnung is 
use Student; 

function klausur (leistung:Vorbereitung) return note; 
function diplom (leistung:vorbereitung) return boolean; 
function bafoeg (leistung:note) return geld; 
end Studienordnung; 

package body Studienordnung is 

function klausur (leistung:vorbereitung) return note is 

separate ; 

function diplom (leistung:vorbereitung) return boolean is 


separate ; 
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function bafoeg (leistung:note) return geld is separate ; 
end Studienordnung; 

sind die Funktionen klausur, diplom, bafoeg nur mit Rumpf¬ 
stümpfen vereinbart. In der Programmbibiiothek sind daher 
die entsprechenden Untereinheiten erforderlich: 

s eparate (Studienordnung) 

function klausur (leistung:Vorbereitung) return note is 
begin 

case leistung is 

when uebertrieben => return 1; 
when gut => return 2; 
when ausreichend => return 3; 
when schlecht => return 4; 
when falsch => return 5; 
end case ; 
end klausur; 

separate (Studienordnung) 

function diplom (leistung:vorbereitung) return boolean is 
begin 

return leistung /= falsch; 
end diplom; 

separate (Studienordnung) 

function bafoeg (leistung:note) return geld is 
begin 

if leistung < 5 

then return (540,0); -- Der Typ geld wurde in 
eise return (0,0); — 2.1.2.2 vereinbart 


end if ; 
end bafoeg; 
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Eine Vereinbarung verbindet einen Namen mit einer Größe des 
Programmes (z.B. einer Variable, einer Record-Komponente, 
einem Typ, einem Unterprogramm, einem formalen Parameter, 
usw.). Der Textbereich, in dem diese Vereinbarung eine Wir¬ 
kung hat, heißt Gültigkeitsbereich der 
Vereinbarung; er beginnt mit der Einführung eines Namens (in¬ 
nerhalb einer Übersetzungseinheit). Da ein Name in verschie¬ 
denen Vereinbarungen auftauchen kann, sind Überschneidungen 
einzelner Gültigkeitsbereiche möglich (siehe hierzu 10.5). 

Die Gültigkeitsbereiche von Vereinbarungen liegen folgender¬ 
maßen fest: 


Größe des 
Programmes 

Ort der impliziten 
oder expliziten 
Vereinbarung 

Gültigkeitsbereich 


Vereinbarungsteil 

eines 

bis zum Ende des 


- Blocks 

- Blocks 

beiiebig 

- Unterprogramm¬ 
rumpfes 

- Paketrumpfes 

- Unterprogramm¬ 
rumpfes 

- Paketrumpfes 


- P,rozeß rümpf es 

- Prozeßrumpfes 


sichtbarer oder ge¬ 
schützter Teil ei¬ 
ner Paketspezifika¬ 
tion 

- der Paketspezifika¬ 
tion und ihrem zu¬ 
gehörigen Paket¬ 
rumpf 

Eingang 

Prozeßspezifika¬ 

tion 

Prozeßspezifikation 
und zugehöriger 
Prozeßrumpf 

getrennt übersetz¬ 
tes Unterprogramm 
oder Paket 


übersetzungseinheit 
selbst mit zugehöri¬ 
gem Rumpf und alle 
ihre Untereinheiten 
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Recordkomponente 
bzw. Diskriminante 

Komponenten- bzw. 
Diskriminantenver¬ 
einbarung in Re¬ 
cordtypvereinbarung 

bis zum Ende des Gül¬ 
tigkeitsbereichs der 
Recordtypvereinba¬ 
rung 

formales 

Argument 

formale Argument¬ 
liste eines 

- Unterprogramms 

- Eingangs 

- Schemas 

bis zum Ende des Gül¬ 
tigkeitsbereichs des 

- Unterprogramms 

- Eingangs 

- Schemas 

Schleifenparameter 
(Laufvariable) 

Schleife 

bis zum Ende der 
Schleife 

Literal eines Auf¬ 
zähl ungstyps 

Typvereinbarung 
des Aufzählungs¬ 
typs 

bis zum Ende des Gül¬ 
tigkeitsbereichs der 
Typvereinbarung 


10.3 SICHTBARKEIT VON GRÖSSEN EINES PROGRAMMS 

Kann eine Programmgröße innerhalb des Gültigkeitsbereichs 
der zugehörigen Vereinbarung direkt mit seinem Namen ange¬ 
sprochen werden, so heißt die Größe, seine Vereinbarung und 
sein Name an dieser Stelle direkt sichtbar. 
Die folgende Tabelle legt die Sichtbarkeitsbereiche für die 
Größen eines Programmes in Abhängigkeit vom Ort der Verein¬ 
barung fest. Allerdings ist hier zu beachten, daß die Ver¬ 
wendung desselben Namens in verschiedenen Vereinbarungen 
möglicherweise zu Überlagerungen führt, aufgrund deren die 
Sichtbarkeitsregelungen noch etwas modifiziert werden müssen 
(siehe 10.5). 
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Größe des 
Programmes 

Ort der 
Vereinbarung 

direkt sicht¬ 
bar in 

Außerhalb des 

Gültigkeitsbe- 
reichs der Ver¬ 
einbarung sicht¬ 
bar durch 

beliebig 

Vereinbarung¬ 
teil im 

- Block 

- Unterpro¬ 
grammrumpf 

- Paketrumpf 

- Prozeßrumpf 

- Block 

- Unterpro¬ 
grammrumpf 

- Paketrumpf 

- Prozeßrumpf 


beiiebig 

- sichtbarer 
Teil 

- geschützter 
Teil 

eines Pakets 

- Paketspezi¬ 
fikation und 
zugehörigern 
-rümpf 

- geschützter 
Teil der Pa- 
ketspezi fi- 
kation und 
im zugehöri¬ 
gen Rumpf 

Voranstellen des 
Paketnamens (Zu¬ 
name) bzw. direkt 
sichtbar bei Ver¬ 
wendung der use- 
Klausel 

Entry 

Prozeßspezifi- 
kation 

Prozeßspezifi¬ 
kation und zu¬ 
gehöriger Pro¬ 
zeßrumpf 

Voransteilen des 

Prozeßnamens 

(Zuname) 

getrennt über¬ 
setztes Unter¬ 
programm oder 
Paket 


der Überset¬ 
zungseinheit 
selbst und al¬ 
len zugehöri¬ 
gen Unterein¬ 
heiten, sowie 
in allen Über¬ 
setzungsein¬ 
heiten, bei 
denen diese in 
einer with-An- 
Weisung aufge¬ 
führt ist. 
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Recordkompo¬ 

nente 

Recordtypver¬ 

einbarung 

Recordtypver¬ 
einbarung und 
zugehöriger 
Darstellungs- 
angabe 

Voranstellen des 
Recordnamens 

Diskriminante 

Recordtypver¬ 

einbarung 

Diskriminan¬ 
tenteil und 
zugehöriger 
Recordtypver¬ 
einbarung 

Voranstellen des 
Recordnamens 


formale Ar¬ 
gumentliste 



formales 

Argument 

- eines Unter¬ 
programmes 

- formale Ar¬ 
gument 1 iste 
und gesamtes 
Unterpro¬ 
gramm 

sichtbar in der 

Parameterzuord¬ 
nung einer aktu¬ 

- eines Ein¬ 
ganges 

- formale Ar- 
gumentliste, 
zugehörige 
accept-An- 
Weisung 

ellen Argument¬ 
liste 


- eines Sche¬ 
mas 

- formale Ar¬ 
gument 1iste, 
Spezifika¬ 
tion und 
Rumpf 


Schleifenpara¬ 
meter (Lauf¬ 
variable) 

Schleife 

ganze Schleife 


Literal eines 
Aufzählungs- 
typs 

Vereinbarung 
des Aufzäh¬ 
lungstyps 

GUI tigkeitsbe- 
reich der Typ¬ 
vereinbarung 



bie obige Tabelle gibt in verschiedenen Fällen durch den so¬ 
genannten ZUNAMEn die Möglichkeit, eine Größe außerhalb des 
Gültigkeitsbereiches ihrer Vereinbarung sichtbar zu machen. 
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Syntax: 


ADA 58: ZUNAHE (ZUN) 


- PGE NAHE - 

- BLOCK NAHE 

- SCHL NAHE 


ADA 59: PROGRAMMEINHEITSNAHE (PGE NAME) 

—p UPG NAME 

- PAK NAME - 

- PZS NAME - 


Semantik: 

Eine Größe kann in der Programmeinheit bzw. in dem Block bzw. 
in der Schleife, in der sie unmittelbar (also nicht in einem 
inneren Konstrukt) vereinbart ist, durch Voranstellen des 
entsprechenden Namens der Programmeinheit bzw. des Blockes 
bzw. der Schleife angesprochen werden. Entsprechend der Stu¬ 
fe, auf welcher eine Größe innerhalb der Programmeinheit auf- 
tritt, kann der Zuname aus allen Namen der umfassenden Kon¬ 
strukte bestehen. 

Hinweise: 

Die Verwendung eines Zunamens ist insbesondere dann sinnvoll, 
wenn in einem inneren Konstrukt der Name der Größe überdeckt 
und damit die Größe nicht mehr direkt sichtbar ist (siehe 
10.5). 

Große Bedeutung besitzt der Zuname für die Bezeichnung von 
Eingängen im Eingangsaufruf eines Prozesses (vgl. 9.2.2) und 
für die Bezeichnung von Größen eines mit einer with-Klausel 
sichtbar gemachten Paketes innerhalb anderer Bibliotheksein¬ 
heiten (vgl. 10.4). 
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10.4 KONTEXTANGABEN 

Entsprechend den Regeln für die Gültigkeit und Sichtbarkeit 
von Größen können getrennt übersetzte Unterprogramme und Pa¬ 
kete und deren Größen zunächst nur in der Einheit selbst und 
in zugehörigen Untereinheiten, nicht jedoch in anderen Bib¬ 
liothekseinheiten angesprochen werden. Eine modulare Pro¬ 
grammierung wäre hierdurch weitgehend unmöglich gemacht. Um 
diesem Mangel abzuhelfen, kann in einer zugehörigen Kontext¬ 
angabe durch with-Klauseln die Umgebung einer Übersetzungs¬ 
einheit festgelegt werden, die im Inneren dieser Einheit be¬ 
nutzt wird, und durch use-Klausein wird die Bezeichnung der 
Größen aus dieser Umgebung ganz wesentlich vereinfacht. 

Syntax: 

ADA 2: KONTEXTANGABE 


^X BIBL EINH NAHE —^-©- 


•O- 


•O 


_ usc -1— pak nahe -KD- 


Name eines Sehemai, Untex- 
pxogxammes odex Paketes, dai 
getxennt übexsetzt uiuxde 
IBibiiotheki einhe.it I 


Name einei Paketei, dai vox¬ 
hex öi einex uiith -Ktauset 
auf>txa.t 


ulith -KCausel 


uic-KZauiet 


Semantik: 

Durch die with-Klausel wird der Name der (getrennt übersetz¬ 
ten) Bibliothekseinheit sichtbar. Alle in dieser Einheit ver¬ 
einbarten Größen werden zugänglich, so, als ob eine Verein¬ 
barung der Bibliothekseinheit am Ende des Paketes Standard 
erfolgte. 

Falls die in der wi_th-Klausel stehende Bibliothekseinheit 

- ein Schema ist, können in der gegebenen Übersetzungseinheit 
Ausprägungen dieses Schemas vorgenommen werden (siehe 6.). 
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-ein Unterprogramm ist, so kann dieses aufgerufen werden 
(siehe 5.). 

- ein Paket ist, so können die dort im sichtbaren Teil ver¬ 
einbarten Größen mit dem Paketnamen als Zuname angespro¬ 
chen werden (vgl. 1.2, 10.3). 

Erscheint der Paketname auch in einer use -Klausel, so brau¬ 
chen die Größen nicht mit dem Paketnamen als Zuname versehen 
zu werden, sondern können direkt mit ihrem eigentlichen Na¬ 
men bezeichnet werden, falls die Eindeutigkeit gewährt ist. 
Kontextangaben können nicht zur Überdeckung von Namen führen 
(siehe 10.5). 

Hinweise: 

(a) Alle vordefinierten Bibliothekseinheiten, außer dem Paket 
Standard, welches stets sichtbar ist, müssen durch with- 
K1ausein bekannt gemacht werden, falls sie verwendet 
werden. 

(b) Es ist gleichgültig, ob eine Bibliothekseinheit einmal 
oder öfter in einer Kontextangabe aufgelistet ist. 

(c) Die Reihenfolge in with-Kl ausein braucht nicht mit der 
tatsächlichen Verarbeitungsreihenfol ge übereinzustimmen. 

(d) Bei der Verarbeitung einer Bibliothekseinheit werden die 
dort in with- Klausein stehenden Bibliothekseinheiten in 
einer Reihenfolge herangezogen, welche die Übersetzung 
des Programms als Ganzes ermöglicht. 

(e) use -Klauseln können auch als eigenständige Vereinbarun¬ 
gen im Vereinbarungsteil von Programmeinheiten auftreten 
(vgl. ADA 18). Entsprechend den Gültigkeitsbereichen der 
Vereinbarungen können also innerhalb einer Bibliotheks¬ 
einheit an verschiedenen Stellen die Größen verschiede¬ 
ner Pakete direkt sichtbar sein. 
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Beispiel: aus 1.1, Version 4: 

with Standard_Funktionen; use Standard_Funktionen; 
function f is 


with Standard_Funktionen; use Standard_Funktionen; 
function fs is 


with f,fs; with Standard_EA; use Standard_EA; 
procedure newton is 
begin 

get (xkl); 
get (eps); 
iteration: loop 

xk:= xkl; 

xkl:= xk - f(xk)/fs(xk); 
exit when abs ((xkl - xk)/xk) < eps; 
end loop iteration; 

end newton; 

Die Funktionen f, fs werden hier als Bibliothekseinheiten 
übersetzt und durch eine entsprechende Kontextangabe im Un¬ 
terprogramm newton bekannt gemacht. 

Darüber hinaus werden die Pakete Standard_Funktionen in f 
bzw. fs und Standard_EA in newton eingeführt; damit sind in 
f bzw. fs die Größen des sichtbaren Teils von Standard_Funk- 
tionen und darüber hinaus in newton auch die Größen des 
sichtbaren Teils von Standard EA sichtbar. 
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10.5 KONFLIKTE BEI DER NAMENSGEBUNG 

Derselbe Name kann durchaus in verschiedenen Vereinbarungen 
eines Programmes eingeführt werden und auch zur Bezeichnung 
verschiedener Größen verwendet werden. Hierbei treten kei¬ 
nerlei Schwierigkeiten auf, solange sich die Gültigkeitsbe¬ 
reiche entsprechender Vereinbarungen nicht überschneiden 
(vgl. 10.2). 

Überschneiden sich die Gültigkeitsbereiche von zwei Verein¬ 
barungen zu demselben Namen, so unterscheidet man zwischen 
einem überladen bzw. einem überdecken eines Namens. 

Das überl aden eines Namens ist nur bei Unterpro¬ 
grammnamen (vgl. 5.7) und Aufzählungstypen möglich (vgl. 

2 . 1 . 1 . 1 . 1 ). 

Dabei spricht man von der Überladung eines Unterprogrammna¬ 
mens, wenn zu einem Namen mehrere Unterprogramme vereinbart 
sind, deren Spezifikationen nicht äquivalent sind. Bei einem 
Aufzählungsliteral kommt es lediglich darauf an, daß dieses 
Literal in verschiedenen Aufzählungstypen auftritt. 

Solche überladene Namen können also verschiedene Bedeutungen 
besitzen, die jedoch durch den Kontext eindeutig auflösbar 
sein müssen. Überladungen dürfen durch Vereinbarungen ein 
und desselben Vereinbarungsteils entstehen. 

Das überdecken eines Namens entsteht durch die 
Verwendung dieses Namens in zwei Vereinbarungen, die nicht 
zur Überladung des Namens führen. Diese Vereinbarungen dür¬ 
fen nicht auf gleicher Stufe im Vereinbarungsteil einer Ein¬ 
heit stehen. Grundsätzlich wird die Bedeutung des Namens ge¬ 
mäß der äußeren Vereinbarung überdeckt, und die zugehörige 
(globale) Größe ist im Gültigkeitsbereich der inneren 
Vereinbarung , d.h. im Sichtbarkeitsbereich der 1 o k a - 
1 e n Größe nicht mehr direkt sichtbar. 
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Das überdecken von Namen wird insbesondere durch die Schach¬ 
tel ung von Unterprogrammen, Paketen, Prozessen und Blöcken 
auftreten. Dabei wird die formale Schemaargumentliste, die 
formale Argumentliste eines Unterprogrammes und der Verein¬ 
barungsteil des Unterprogrammrumpfes als ein Vereinbarungs¬ 
teil aufgefaßt. In ähnlicher Weise gelten formale Schemaargu¬ 
mentliste, Paketspezifikation und Vereinbarungsteil des Pa¬ 
ketrumpfes als ein Vereinbarungsteil. 

Eine überdeckte Größe, welche unmittelbar in einem Unterpro¬ 
gramm, Paket oder Prozeß vereinbart ist, d.h. lokale Größe 
einer solchen Einheit ist, wird immer sichtbar durch Angabe 
des Namens des Unterprogrammes, Paketes oder Prozesses als 
Zuname der Größe (siehe 10.3). 

Letztlich bleibt die Frage zu beantworten, in welcher Weise 
Namenskonflikte zwischen einer lokalen Größe einer Biblio¬ 
thekseinheit und den durch Kontextangaben direkt sichtbar ge¬ 
machten Größen anderer Bibliothekseinheiten gelöst werden. 

An einer beliebigen Stelle einer Bibliothekseinheit kommen 
für solche Konflikte alle Größen von solchen Paketen in Be¬ 
tracht, welche in einer an dieser Stelle gültigen use -Klau- 
sel aufgeführt sind. Es gilt dann: 

- Eine Größe wird direkt sichtbar, falls sie im sichtbaren 
Teil genau eines solchen Paketes steht und nicht durch eine 
lokale Vereinbarung überdeckt wird. 

- Ein Aufzählungsliteral wird genau dann direkt sichtbar, 
falls dessen Name nicht schon anderweitig direkt sichtbar 
ist, und in jedem Fall, wenn es ein Zeichenliteral (z.B. 

'+', 'a', usw.) ist. 

- Ein Unterprogramm wird direkt sichtbar, wenn dessen Name 
durch keine Größe - lokal vereinbart oder nach den beiden 
ersten Regeln - überdeckt wird und die Unterprogrammspezi- 
fikation von jeder anderen sichtbaren verschieden ist. 
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Die Verwendung von use-Klausein führt also in keinem Fall zu 
Schwierigkeiten, da die Größen sichtbar gemachter Pakete 
nachrangig direkt sichtbar werden und somit direkt sichtbare 
lokale Größen nicht überdeckt werden. 

Hinweise: 

Namenskonflikte lassen sich auf einfache Art und Weise durch 
die Umbenennung entsprechender Größen (siehe 2.8) oder durch 
die Verwendung von Zunamen (siehe 10.3) umgehen. 

Speziell bei Werten aus Aufzählungstypen können Mehrdeutig¬ 
keiten, die durch überladen entstanden sind, mittels der 
Qualifizierung dieser Werte in der Form des qualifizierten 
Ausdruckes (siehe ADA 31, Abschnitt 3.10) ausgeschlossen 
werden. 


10.6 ÜBERSETZUNG UND AUSFÜHRUNG EINES PROGRAMMES 

Die Übersetzung eines Programmes kann in mehre¬ 
ren Schritten erfolgen, wobei jeweils in einem Schritt eine 

Folge von Übersetzungseinheiten übersetzt wird. 

Die Reihenfolge der Übersetzung von Übersetzungseinheiten ei¬ 
nes Programmes ergibt sich aus den Sichtbarkeitsregeln: 

- Eine Einheit darf erst übersetzt werden, nachdem alle Ein¬ 
heiten, deren Namen in einer with-Klausel auftauchen, über¬ 
setzt sind. 

- Ein Unterprogramm oder ein Paketrumpf darf erst nach der 
zugehörigen Unterprogrammspezifikation bzw. Paketspezifika¬ 
tion übersetzt werden. 

- Untereinheiten dürfen erst nach der zugehörigen Oberein¬ 
heit übersetzt werden. 

Ansonsten ist die Reihenfolge beliebig. 


18 Kaucher IV - ADA 
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Die Wirkung der Übersetzung einer Übersetzungseinheit ist 
die Vereinbarung der Einheit als Bibliothekseinheit (bei 
UNTERPROGRAMM SCHEMA SPEZIFIKATION, PAKET SCHEMA SPEZIFIKA¬ 
TION, UNTERPROGRAMM SPEZIFIKATION, UNTERPROGRAMM ERZEUGUNG, 
PAKET SPEZIFIKATION, PAKET ERZEUGUNG) bzw. die Vereinbarung 
der Einheit und Festlegung des zugehörigen Rumpfes. 

Werden Änderungen in einer Übersetzungseinheit vorgenommen, 
so werden diese Einheit und jede Übersetzungseinheit, in 
welche sich diese Änderungen auswirken könnten, neu über¬ 
setzt. Dies können eventuell vorhandene Untereinheiten oder 
Übersetzungseinheiten sein, in deren with -Kl ausein die ge¬ 
änderte Einheit genannt wird. Eine Implementierung darf die 
Neuübersetzung auf die tatsächlich betroffenen Übersetzungs¬ 
einheiten beschränken. 

Speziell Änderungen in einer Untereinheit oder einem Unter¬ 
programm- bzw. Paketrumpf wirken sich nicht auf andere Über¬ 
setzungseinheiten aus, so daß hier nur diese Einheit neu 
übersetzt wird. 

Die Ausführung eines Programmes beginnt mit der 
Ausführung eines Unterprogrammes, welches die übliche Funk¬ 
tion eines Hauptprogrammes übernimmt. Dabei legt die Sprache 
nicht fest, wie ein Unterprogramm als Hauptprogramm ausge¬ 
zeichnet wird. Vor der Ausführung des Hauptprogrammes werden 
alle durch das Hauptprogramm benutzten Bibliothekseinheiten 
v e r a r b e i t e t . Dies sind die in den wi_th-Kl ausein 
des Hauptprogrammes genannten Einheiten und deren Unterein¬ 
heiten, sowie die in deren with-Klausein genannten Einheiten 
und Untereinheiten, und so weiter. Die Verarbeitung der Bib¬ 
liothekseinheiten läuft so ab, daß eine Bibliothekseinheit 
bereits verarbeitet sein muß, wenn eine andere,davon abhän¬ 
gige Bibliothekseinheit, verarbeitet werden soll. Falls ver¬ 
schiedene Reihenfolgen für die Verarbeitung möglich sind, 
so darf die Bedeutung des Programmes nicht von einer be¬ 
stimmten Reihenfolge abhängen. 
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11. EIN- BZW. AUSGABE UND HANDHABUNG VON FILES 


Die Ein- bzw. Ausgabe eines Programms beschreibt den Trans¬ 
fer von Daten von bzw. zu einem externen Datenträger oder 
Gerät (sie ist daher stets maschinenabhängig). In der Regel 
interessiert den Benutzer nur die Schnittstelle seines Pro¬ 
gramms, wie und wo die Daten abgespeichert werden, ist ihm 
dagegen weitgehend gleichgültig. 

Die Ein- und Ausgabe sind wegen der Maschinenabhängigkeit 
nicht ein Bestandteil des Sprachkerns, d.h. sie sind nicht 
im Paket Standard beschrieben, welches zu jedem ADA-Programm 
stets automatisch hinzugefügt wird. Sondern es stehen drei 
vordefinierte Pakete zur Verfügung. Im einzelnen sind dies 
das Paketschema input_output, das Paket text_io und das Pa¬ 
ket low_level_io. 

Diese Pakete stellen nicht nur Unterprogramme für Ein/Ausgabe 
zur Verfügung, sondern beschreiben auch die Files (Dateien), 
die zur externen Aufbewahrung von Daten verwendet werden. 

Files sind eine zusätzliche Klasse von Typen. Sie beschrei¬ 
ben eine Folge von Daten gleichen Typs, also eine beliebig 
große Anzahl von Komponenten eines Typs. 

In den folgenden Diagrammen sind die in Klammern angegebenen 
Kommentare (£t£e), (-extern), {to), [ncum], (-6 pacUng), [ivxdth), 
(manlMiAa .), (^xpomntj, [fisiacÄ), Uou)eA_caAz] die Namen der 
formalen Argumente. 

Da man mit solchen Files auch strukturierte Datentypen bil¬ 
den kann und sie z.B. als Argument iri eine Prozedur eingege¬ 
ben werden können, wurden sie in die Syntaxdiagramme einge¬ 
arbeitet. 

Man beachte, daß man Files nur vereinbaren kann, falls das 
entsprechende Ein/Ausgabepaket sichtbar ist. 


18 * 
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In Abschnitt 4.3 wurden bereits die einfachsten und wichtig¬ 
sten Ein- und Ausgabeprozeduren besprochen. 


11.1 DAS PAKETSCHEMA INPUT_OUTPUT 

Das Paketschema input_output beschreibt die Ein- und Ausgabe 
auf Files von einem festgelegten Typ. Die Werte werden in 
der internen Form abgelegt (Es kann jedoch ein Dnterschied 
zwischen der internen Form in einem Programm und auf einer 
Datei bestehen). Der Komponententyp wird bei der Erzeugung 
von Inkarnationen des Schemas als aktuelles Schemaargument 
angegeben. 

Syntax: 

Aus 

ADA 11: PAKETERZEUGUNG 

O * (B.CII.AZ.I.G.F.A.ST.REC.ZJ 
— package - PAK NAME ~ ii - new — Q nput_output 



Komponente ii typ 


Semantik: 

Es wird ein Ein/Ausgabepaket für den Komponententyp T er¬ 
zeugt. Files mit diesem Komponententyp können nun vereinbart 
werden. Unterprogramme für Ein- und Ausgabe, sowie zur Ver¬ 
waltung von Files vom Komponententyp T stehen zur Verfügung. 


11.1.1 DIE VERWALTUNG VON FILES 

Mit der Erzeugung eines Paketes für Ein- und Ausgabe auf 
Files mit Komponententyp T werden die Filetypen in_file, 
out_file und inout_file vereinbart. 

type in_fi 1 e jis. 1 imited private ; 
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type out_file is^ 1 imited private ; 
type inout_file is_ limited private; 

Syntax: 


ADA 22: IF TYP I EingabeiUeti/p) 


-ZUN — IF TYP NAME —| 

I— zun —GülZüD-^ 


ADA 22: OF TYP 1^9 abciitetyp) 


— r— ZUN — OF TYP NAME —i 
I— ZUN -( out flle^-L 


ADA 22: IOF TYP l£tn/Auigabi:$i.£e.ti/p) 


Semantik: 


T 


ZUN — IOF TYP NAME 
ZUN -(inout_file~)- 


3 


Es handelt sich hierbei um limitierte geschützte Typen für 
die Beschreibung von Files mit Komponententyp T, die nur für 

die Eingabe (in_fi 1 e) (Abkürzung IF), nur für die Ausgabe 

(out_file) (OF) oder für Ein- und Ausgabe (inout_file) (IOF) 
vorgesehen sind. 


Als Zuname wird in der Regel der Name des erzeugten Ein/Aus¬ 
gabepaketes angegeben werden. 

Variable von diesen Typen, die nun vereinbart werden können, 
wirken in Ausdrücken wie Konstante, da keine Wertzuweisung 
möglich ist. Sie können ihren Wert jedoch durch einzelne An¬ 
weisungen verändern. 

Filetypen dürfen auch als Komponententypen strukturierter 
Typen auftreten. 


Hinweis: 

Im Gegensatz zu PASCAL kann in ADA schon zur übersetzungs- 
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zeit geprüft werden, ob ein unerlaubter Lesezugriff (auf 
out_files) oder Schreibzugriff (auf in_files) erfolgt. Au¬ 
ßerdem gibt es durch die inout_files die Möglichkeit, ein 
File "gleichzeitig", d.h. ohne Zurücksetzen, zu beschreiben 
oder zu lesen. 

Mit der Erzeugung eines Paketes aus dem Schema input_output 
wird außerdem der integer Typ file_index vereinbart (Abkür¬ 
zung FI). 

type file_index i_s ränge 0 .. w; 

Syntax: 

Aus 

ADA 22: I TYP 

- ZUN - (fllejndex) - 


Semanti k: 

file_index ist ein implementierungsabhängiger integer Typ, 
der zur Angabe von Positionen innerhalb eines Files vom Kom¬ 
ponententyp T dient. 

Hinweise: 

Die obere Grenze w ist implementierungsabhängig und wird 
durch file_index'last angegeben. Dieser Wert kann für Files 
verschiedener Komponententypen verschieden sein. 

Man kann sich ein File auch als ein beliebig langes eindimen¬ 
sionales Array vorstellen. Die Elemente dieses Files lassen 
sich jedoch nicht wie bei einem Array einfach durch Indizie¬ 
rung bestimmen, sondern können nur über Positionsangaben und 
Ein/Ausgabeprozeduren angesprochen werden. 

Wenn man entsprechende Unterprogramme zur Verfügung stellt, 
kann man ein File auch auffassen als eine Folge von Arrays 
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mit dem Komponententyp des Files. Z.B. kann in einem File 
von reellen Zahlen jeweils ein Paar aufgefaßt werden als 
Real- und Imaginärteil einer komplexen Zahl. 

Ein File besitzt eine aktuelle Länge - die An¬ 
zahl der definierten Elemente -, eine Endposition 
- die Nummer des letzten definierten Elementes, bzw. 0, 
falls das File leer ist. Ein Eingabefile besitzt eine ak¬ 
tuelle Leseposition- die Nummer des näch¬ 
sten zu lesenden Elementes. Ein Ausgabefile besitzt eine 
aktuelle Schreibposition- die Nummer 
des Platzes, der als nächstes beschrieben wird. Ein Ein/Aus¬ 
gabefile besitzt sowohl eine aktuelle Lese- als auch Schreib¬ 
position. Alle diese Positionsnummern sind vom implementie¬ 
rungsabhängigen integer Typ file_index. 

Sollen die Files eines Programmes über das Ende des Pro¬ 
grammes hinaus existieren, so müssen sie externen Files zu¬ 
geordnet werden. Dazu dienen die FILEVERWALTUNGSPROZEDUREN. 

Syntax: 

Aus 

erzeugt ex.terne* Fite a 

ordnet externe* Fite a Internem 
Fite s zu 

löit die Verbindung zu externem Fite 
lö&cht externe* Fite 


Wie für alle Fileverwaltungsprozeduren und Ein/Ausgabeun¬ 
terprogramme ist der Name des formalen Argumentes für das 
interne File file und der für das externe File name. Der 
Name des externen Files ist implementierungsabhängig. 

Diese 4 Prozeduren gelten auch für die im nächsten Ab¬ 
schnitt eingeführten Textfiles. 


ADA 53: FILEVERWALTUNGSPROZEDURAUFRUF 

♦ - (IF,0F,10F,ITF,0TFJ 

Q Fe(0F, IOF,0TF) 



f VAR -Q- ST A • 

f VAR — O- ST A - (T> 

r VAR-©— 



interne* File 6 
Iflte) 


- ST A - (T) 


externe* Fite < 
Inantel 
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Semantik: 

create schafft ein neues externes File a, dessen Elemente 
alle Undefiniert sind. Dieses File wird eröffnet, d.h. dem 
internen File 3 zugeordnet. Die Schreib- oder Leseposition 
wird auf 1 gesetzt. 

open ordnet das existierende externe File a dem internen 
File 3 zu. Die Schreibposition wird auf 1 gesetzt, die Le¬ 
seposition auf das 1. definierte Element oder auf 1, falls 
das File leer ist. 

close löst die Zuordnung zu einem externen File wieder auf. 

delete löscht ein externes Filea. Dieses darf nicht mehr 
eröffnet werden. 

Einem internen File kann höchstens ein externes File zuge¬ 
ordnet werden. Jedoch können mehrere interne Files dem¬ 
selben externen File zugeordnet werden. 

Diese vier Prozeduren regeln also die Zuordnung von exter¬ 
nen zu internen Files. Im Gegensatz zu PASCAL geschieht das 
innerhalb des Programmes und nicht über die Programmparame¬ 
terliste. Das heißt, daß die Ausführung des gleichen Pro¬ 
grammes mit verschiedenen Dateien unmöglich ist, ohne die 
Programmeinheit, die die Ein- und Ausgabe beschreibt, neu 
zu übersetzen (wie in FORTRAN). Im Gegensatz zu PASCAL 
werden alle Files bei der Eröffnung initialisiert. 

Zur Unterstützung der Fileverwaltungsprozeduren dienen die 
Funktionen is_open und name. 



11.1.2 Ein/Ausgabe mit Files 
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Syntax: 

Aus 

ADA 55: t E/A STANDARDFUNKTIONSAUFRUF 

—HT-b l- (is_o P erQ -©-^- 

Mt-st )—(nT^T)-©-^- 



wofc-t tatti Vitt enö&inel 

Harne, dei zugeoidneten externen Filet 


Semantik: 

is_open liefert den Wert true, falls dem File 3 ein exter¬ 
nes File a zugeordnet ist, name bestimmt dessen Namen. 


11.1.2 EIN- BZW. AUSGABE MIT FILES 


Das Lesen eines Elementes von einem File vom Typ in_fi 1 e 

oder inout_file geschieht mit der Standardprozedur read. 


Syntax: 

Aus 


ADA 54: E/A PROZEDURAUFRUF 

e = {B,CH,AZ,I,G,F,A,ST,REC,Z} 


— f read) — 


I-®-p IF A —| 

L IOF A -L"0— t 


einzule&ende 

Variable 


VAR —©- 


ISile) 


Semantik: 

read liest das Element an der aktuellen Leseposition und 
setzt diese auf das nächste definierte Element; falls kei¬ 
nes vorhanden, wird um 1 erhöht. Die Ausnahme end_error 
wird ausgelöst, falls die Leseposition größer als die End- 
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Position wird, data_error, falls der Wert nicht definiert 
oder (evtl.) nicht von passendem Typ ist. T bezeichnet den 
Komponententyp des Files. 

Man beachte, daß mit einem Aufruf von read stets nur ein 
Element gelesen wird. ÄXo.m ist Ausgabeargument der Eingabe¬ 
prozedur. 

Das Schreiben eines Wertes auf ein File vom Typ out_file 
oder inoutfile geschieht mit der Standardprozedur write. 


Syntax: 


Aus 


ADA 54: E/A PROZEDURAUFRUF 



reo 


Semantik: 

write beschreibt den Platz der aktuellen Schreibposition und 
erhöht diese um 1. Falls die Endposition überschritten wird, 
so wird diese auch erhöht. 

Der Komponententyp des Files ist T. Mit einem Aufruf von 
write kann nur ein Ausdruck auf das File geschrieben werden. 

Man kann die Prozeduren read und write auch für Textfiles 
verwenden, doch muß man sich dann darüber klar sein, daß der 
Komponententyp character ist, und nicht die bei get und put 
übliche Konvertierung vorgenommen wird. 

Normalerweise wird ein File von Anfang an Komponente für 
Komponente beschrieben und so auch wieder gelesen werden. 

Die folgenden Prozeduren verändern die Lese- bzw. Schreib¬ 
position. 
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Syntax: 

Aus 

ADA 53: FILEVERHALTUNGSPROZEDURAUFRUF 

Poi Ltioniändt'iunge.n 

itXzt Lc&ipoiition au& I. Etemnt 
atze. Schwibpoiition au& 1 
ictzc Luepoiition outf y 
itfze Sch\cibpoiition aui y 
Hitze Endpohition aui Y 


- (resetread) - F - 


(reset wrl te 


Xi> 


F6(0F,10F.0TF) 


HSTTÜd)-0_F6UF 1 IOF ± im 

F6{0F,10F.0TF) F ^ 


{set_wrtte) —i 
{truncate) -*—CO - ^ 


<Dn 



Semantik: 

set_read bzw. set_write setzen die Lese- bzw. Schreibposi¬ 
tion auf y, reset_read setzt die Leseposition auf das er¬ 
ste definierte Element bzw. 1, falls kein Element definiert 
ist. reset_write setzt die Schreibposition auf 1. truncate 
setzt die Endposition auf den angegebenen Wert und ändert 
die Länge entsprechend. Ist der angegebene Wert größer als 
die Endposition, so erfolgt use_error. 

Bemerkungen: 

(1) Ein open auf ein leeres Eingabefile oder Ein/Ausgabe¬ 
file bewirkt, daß die aktuelle Leseposition = 1 und die 
aktuelle Endposition = 0 ist. Auch durch set_read kann 
die Leseposition größer als die Endposition werden. 

Die Ausnahme end_error wird nicht ausgelöst. 

(2) Anders als in PASCAL bewirkt reset write nicht, daß alle 
Elemente des Files Undefiniert werden. Dem rewrite(f) 
von PASCAL entspricht in ADA 

reset_write(f); truncate(f,1); 

Zum Feststellen der aktuellen Position und Zustand der Files 
dienen die folgenden Funktionen. 
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Syntax: 

Aus 

ADA 55: r E/A STANDARDFUNKTIONSAUFRUF 


[T-B )- (end_ 0 f_fUe> -(T)- 


F6dF.10F.lTF) 


-O—i 


4T.Fl )-p Cnext_readj -Q F6{1F.10F.1TF) - f «fetucMe Lwe 


- C nextiwrü T) —(D ^tOF.lOF.OTF) 

-düD-i 

—TlastT—'— 


FA-©— 




- f A - 




kh/i*. Fittinde. eviUcht 


" Schncib- 
Fiteläitge. 
Endpu&ttion 


vom Typ 
{HlJuno 


Semantik: 

Die Funktionen next_read bzw. next_write liefern die aktu¬ 
elle Lese- bzw. Schreibposition, die Funktionen size bzw. 
last die Länge bzw. Endposition. end_of_file ist true, falls 
die Leseposition größer als die Endposition ist. 

Es spielt keine Rolle, ob die externen Files sequentiell, 
indexsequentiell oder andersartig organisiert sind. Die Ver¬ 
wendung der verschiedenen Positionen erlaubt im Programm ein 
Hin- und Herspringen in Files. Sollte dieses bei speziellen 
externen Files verboten sein (z.B. Rücksetzen eines Loch¬ 
streifens), so erfolgt use_error. 


11.1.3 AUSNAHMESITUATIONEN 

Die Ausnahme status_error wird ausgelöst, falls 

- ein create- oder open-Aufruf für eine bereits eröffnete 
Datei erfolgt (ADA 53). 

- ein Aufruf einer anderen Prozedur oder Funktion für eine 
nicht eröffnete Datei erfolgt (ADA 53). 

Die Ausnahme name_error wird ausgelöst, falls 

- beim create-Aufruf eine externe Datei mit dem angegebe¬ 
nen Namen a bereits existiert (ADA 53). 
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- beim open-Aufruf eine externe Datei mit dem angegebenen 
Namen a nicht existiert oder der Zugriff auf die Datei a 
nicht erlaubt ist (ADA 53). 

Die Ausnahme device_error wird ausgelöst, falls 

- eine Ein/Ausgabeaktion, bedingt durch einen Systemfehler 
der betreffenden Datei oder des Gerätes, nicht korrekt 
beendet werden kann. 

Die Ausnahme use_error wird ausgelöst, falls 

- eine Aktion verlangt wird, die nicht mit dem externen 
File verträglich ist, z.B. das Rücksetzen eines Lochkar¬ 
tenlesers, das Schreiben auf eine schreibgeschützte Da¬ 
tei oder das Verlängern einer Datei vorgegebener Länge. 

Die Ausnahme data_error wird ausgelöst, falls 

- ein nicht definierter Wert gelesen wird. 

Die Ausnahme data_error kann ausgelöst werden, falls 

- ein Wert gelesen wird, der nicht mit dem Komponenten¬ 
typ kompatibel ist. 

Die Ausnahme end_error wird ausgelöst, falls 

- gelesen wird, obwohl end_of_file = true ist, d.h. die 
Leseposition größer als die Endposition ist. 


11.2 DAS PAKET TEXT_IO 

Die Ein/Ausgabemöglichkeiten, die das Paketschema input_- 
output anbietet, reichen zwar zum Zwischenspeichern von Da¬ 
ten aus, doch für die Kommunikation mit einem menschlichen 
Benutzer müssen die Daten in einer lesbaren Form ein- und 
ausgegeben werden können. Zu dem Ein/Ausgabevorgang kommt 
jetzt also noch eine Konvertierung hinzu. 
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11.2.1 DIE VERWALTUNG VON TEXTFILES 


Das Paket text_io enthält eine Ausprägung des Schemas 
input_output mit dem Typ character und die Vereinbarung ab¬ 
geleiteter Filetypen für Eingabe- und Ausgabefiles. 

package character_io is new input_output (character); 

type in_fi 1 e is new character_io.in_file; 

type out_file i_s new character_io.out_file; 


Syntax: 


ADA 22: ITF TYP 

Eingabctixtiite.tifp 


T 


ZUN —ITFTYP NAME — 
-ZUN — Qn_f ne> 


ADA 22: OTF TYP 

A uigabeXtxtiiteXyp 


■ ZUN - 


■ OTF TYP NAME • 


Semantik: 


■ ZUN — (out.flle) - 


Es gibt nur Eingabedateien (Abkürzung ITF) und Ausgabedatei¬ 
en (OTF). Da mit Hilfe dieses Paketes für solche Files vom 
Komponententyp character zusätzliche Operationen möglich 
sind, werden diese Files jetzt Textfiles genannt. Als Zuname 
wird in der Regel der Name text_io auftreten. 

Auf Textfiles sind selbstverständlich auch die Funktionen 
und Prozeduren des Paketes character_io anwendbar, jedoch 
sind nicht alle Kombinationen sinnvoll und haben klar defi¬ 
nierte Wirkungen. 

Die Zeichen, mit denen Textfiles beschrieben oder gelesen 
werden, müssen zu den 95 druckbaren ASCII-Zeichen gehören. 
Die Wirkung eines Programmes, das dagegen verstößt, ist im- 
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plementierungsabhängig. 

Textfiles bestehen aus einer Folge von Zeilen, jede Zeile 
aus aufeinanderfolgenden Zeichenpositionen, den Spalten. Die 
Nummerierung beginnt jeweils bei 1. Jedes Textfile besitzt 
also eine Zeilen- und eine Spaltenposition, die beide von 
dem integer Untertyp natural (Abkürzung N) sind. Die Zei¬ 
len- und Spal tenposi tion beschreiben die 
für den nächsten Ein- oder Ausgabebefehl relevante Position, 
sie können durch folgende Prozeduraufrufe gesetzt werden. 


Syntax: 


Aus 


ADA 53: FILEVERWALTUNGSPROZEDURAUFRUF 



ietze Spaltenpotition auf r 


idifizibt neue Zelte 
♦ v LeenzeÄJten 


übeAlieAt Zelte 
* v Zelten 


set_col setzt die Spaltenposition auf den Wert y. Falls y 
größer als die Zeilenlänge ist, erfolgt 1ayout_error. 

new_line beendet die Ausgabe, skip_line die Eingabe einer 
Zeile, es werden v-1 Leerzeilen ausgegeben bzw. v-1 Zeilen 
überlesen. Alle Prozeduren sind auch in einer Version vor¬ 
handen, in der auf die Angabe des Textfiles verzichtet wer¬ 
den kann. set_col und new_line beziehen sich dann auf die 
aktuelle Standardausgabedatei, skip_line auf die aktuelle 
Standardeingabedatei. Das formale Argument n (an anderer 
Stelle steht spacing) hat als Vorbesetzung den Wert 1. 
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Zur Ermittlung der aktuellen Zeilen- bzw. Spaltenposition 
dienen die Funktionen col und line. 


Syntax: 

Aus 


ADA 55: 1 E/A STANDARDFUNKTIONSAUFRUF 



Spattzn- 


posltion l>OI 


ItÄJLzn- 


j vom Typ 
I natuAat 


Standard output 
l£t*c) 


Semantik: 

col liefert die aktuelle Spaltenposition, line die aktuelle 
Zeilenposition. Fehlt die Angabe von file, so wird die 
Standardausgabedatei genommen. 

Verändern der Zeilenlänge: 

Die Zeilenlänge eines Files kann fest oder beliebig sein. 
Beliebig heißt dabei, daß das File Zeilen verschiedener Län¬ 
ge haben kann. Das wird etwa bei Eingabe vom Bildschirm sehr 
wünschenswert sein. Die Zeilenlänge eines Files kann gesetzt 
werden. 

Syntax: 

Aus 

ADA 53: FILEVERWALTUNGSPROZEDURAUFRUF 



•üeAt v 

U^e) (ipactiifl) 


setze. Z&itentänge. au{ v |>0) 
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Semantik: 

Die Zeilenlänge des angegebenen files oder der Standardaus¬ 
gabedatei wird auf v gesetzt. Ist v = 0, so ist die Zeilen¬ 
länge beliebig. 


Syntax: 

Aus 

ADA 55: I E/A STANDARDFUNKTIONSAUFRUF 


Ztitcnlänge |>0) 

<D- 


1 ne_length ) — {(J— 


- ITF A - 
■ OTF A - 


l^ee) 


Semantik: 

Der Wert der Funktion ist die Zeilenlänge des Textfiles. 
Wieder bedeutet der Wert 0, daß die Zeilenlänge des Text¬ 
files beliebig ist. 

Fehlt die Angabe des Files, so wird die Standardausgabedatei 
verwendet. 


Ende einer Zeile: 

Für Textfiles mit beliebiger Länge kann das Ende einer Zeile 
einer Eingabedatei mit der Funktion end_of_line festgesteilt 
werden. 

Syntax: 

Aus 

ADA 55: B E/A STANDARDFUNKTIONSAUFRUF 


(end_of_1 i ne) —(T}- 


— ITF A 

-—©“ 

4 tandaAd input 
I &Ut ) 


walin., iatti Zeifenemfe e.vieÄ.cht 


19 Kaucher IV - ADA 
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Semantik: 

Falls die Zeilenlänge in dem angegebenen Textfile (oder der 
Standardeingabedatei) beliebig ist und die. aktuelle Spalten¬ 
position die tatsächliche Länge der aktuellen Zeile über¬ 
schreitet, so ist der Wert von end_of_line = true, ansonsten 
= false. 

Das Ende einer Zeile eines Textfiles wird durch ein speziel¬ 
les Zeilenendezeichen markiert, das nicht zum Zeichensatz 
gehört und auch nicht gelesen werden kann. . 

Die Standardein- und ausgabedatei werden zu Beginn der Aus¬ 
führung der Programmeinheit eröffnet und implementierungsbe¬ 
dingten externen Files zugeordnet. Sie können vom Benutzer 
festgestellt und umdefiniert werden. 

Syntax: 

Aus 

ADA 53: FILEVERWALTUNGSPROZEDURAUFRUF 

set lnput) - (7) - ITF A - 

set output") - ( 7 ) - OTF A - 

TexXfile B 
IStfe) 



-®- 1 


B neue StandaxdeÄn- 
beul. anigabedatei 


Semantik: 

Das angegebene Textfile wird die aktuelle Standardein- bzw. 
ausgabedatei. 

Syntax: 

Aus 

ADA 55: T E/A STANDARDFUNKTIONSAUFRUF 


T-ITF )-p^standard_1 npüT 


^current_input^- 


a 




-(T-OTF tandard_output 


-^current_output}- 


a 




an fängliche 

-Q- aktuelle 

anfängliche 
— aktuelle 


StandaAdeingabedaXei 


Standa\daiu> gabedatei 
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Semantik: 

Die Funktionen standard_input bzw. standard_output liefern 
die anfängliche Standardein- bzw. Standardausgabedatei, 
current_input bzw. current_output die aktuelle. 

Hinweise: 

Man kann sich ein Textfile wie eine Matrix vorstellen, deren 
Zeilen verschieden lang sein können. 

Files mit fester Zeilenlänge eignen sich gut für formatierte 
Ein/Ausgabe. 


11.2.2 EIN- BZW. AUSGABE MIT TEXTFILES 

Die Prozeduren get bzw. put sind mehrfach überladene Proze¬ 
duren für die Eingabe bzw. Ausgabe von Daten verschiedener 
Typen mit einem Textfile. 


11.2,2.1 EIN- BZW. AUSGABE C ÜR ZEICHEN UND 
ZEICHENKETTEN 

Das Paket text_io enthält die Paketerzeugung des Paketes 
character_io. 

package character_io is new input_output (character); 

Die Textfiletypen in_file und out_file werden vereinbart und 
hier mit ITF und OTF abgekürzt. 

Für das Einlesen von Zeichen steht die Prozedur get bereit. 


19* 
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Syntax: 

Aus 

ADA 54: E/A PROZEDURAUFRUF 




-®~ j- HF A ~Q~| 


(fctcl 


CH VAR -0- 

Utem) 


Semantik: 

get liest das Zeichen des angegebenen files oder der Stan¬ 
dardeingabedatei, das durch die aktuelle Zeilen- und Spalten¬ 
position bestimmt ist. Die Spaltenposition wird um 1 erhöht. 
Ist dann bei einem File fester Länge die Spaltenposition 
größer als die Zeilenlänge, so wird die Zeilenposition um 1 
erhöht und die Spaltenposition auf 1 gesetzt, also an den 
Anfang der nächsten Zeile gesprungen. Das gelesene Zeichen 
wird in der CH Variablen itm übergeben. 

Hinweis: 

Das Zeichen auf dem Textfile entspricht nicht der Syntax ei¬ 
ner CH KONSTANTEN, denn es wird nicht in Apostrophe einge¬ 
schlossen. 

Zur Ausgabe eines Wertes vom Typ character dient die Proze¬ 
dur put. 

Syntax: 

Aus 


ADA 54: E/A PROZEDURAUFRUF 



liiU) 


(■cfem) 
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Semantik: 

Der CH. Ausdruck Itm wird ausgewertet und an die Stelle des 
angegebenen ^äJLq, bzw. der Standardausgabedatei geschrieben, 
die durch die aktuelle Zeilen- und Spaltenposition bestimmt 
wird. Die Spaltenposition wird um 1 erhöht. Ist dann bei ei¬ 
nem File fester Länge die Spaltenposition größer als die 
Zeilenlänge, so wird ein Zeilenendezeichen ausgegeben und 
die Zeilenposition um 1 erhöht und die Spaltenposition auf 
1 gesetzt. 


Man kann ein Textfile, das ja eine Folge von Zeichen be¬ 
schreibt, auch als eine Folge von Zeichenketten auffassen. 
Die Prozeduren get bzw. put für Zeichenketten bedeuten die 
mehrfache, der Stringlänge entsprechende Ausführung von get 
bzw. put für Zeichen. 


Syntax: 

Aus 


ADA 54: E/A PROZEDURAUFRUF 


-CÜD-®- |- ITF A —Q-| 

-<HD -®-|~ OTF A -Q-| 


ST VAR —()>■ 
ST A-(T> 




Semantik: 

get (item) ist äquivalent zu 
for i i_n item'first .. item'last 
loop 

get (item(i)); -- get für CH Variable 
end loop ; 

Es werden also der Stringlänge entsprechend viele Zeichen 
gelesen. 
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Für die Eingabe existieren zusätzlich die Funktionen 
get_string und get_line. 

Syntax: 

Aus 

ADA 55: ST E/A STANDARDFUNKTIONSAUFRUF 





Semantik: 

get_string überliest auftretende Trennzeichen, das sind 
Leerzeichen, Tabulatoren oder Zeilenendezeichen, und über¬ 
gibt den folgenden String als Ergebnis. Der String ist von 
beliebiger Länge und wird durch ein Trennzeichen beendet. 

getjline übergibt alle Zeichen von der aktuellen Leseposi¬ 
tion (bestimmt durch Zeilen- und Spaltenposition) bis zum 
Zeilenende als Ergebnis. Die Zeilenposition wird um 1 er¬ 
höht, die Spaltenposition auf 1 gesetzt. Beachte, daß ein 
leerer String übergeben wird, falls die Spaltenposition 
gleich dem Zeilenende ist. 

item:= get_string; 
ist äquivalent zu 

loop -- überlesen von Trennzeichen 

while end_of_line () 
loop skip_line; 
end loop ; 

get (ch); — Bei fester Zeilenlänge wird Zeilenende- 

-- Zeichen überlesen. 
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exit when ch /= ' 1 or eise ch /= ascii.ht; 
end loop ; 

— ch ist 1. Zeichen des String 

i := 1; 
loop 

item (i):= ch; 
get (ch); 

exit when ch = '' or eise ch = ascii .ht 

or eise col() =1 -- Zeilenende bei fester 

— Laenge 

or eise end of line (); — Zeilenende bei 

-- variabler Laenge 


item:= get_line(f); 
ist äquivalent zu 
i := 1; 

while col(f) <= 1ine_1ength(f) 

10OP 

get (f,item(i)); 
i := i+1; 
end loop ; 

if end_of_1ine (f) then skip_1 ine (f); 

— Bei fester Laenge automatisch mit get. 


Syntax: 

Aus 

ADA 54: E/A PROZEDURAUFRUF 



(j-cle) \Um) 
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Semantik: 

Der ST Ausdruck Itm wird ausgewertet. Fehlt die Angabe von 
, so wird auf die Standardausgabedatei geschrieben. 

put schreibt der Stringlänge entsprechend viele Zeichen. 
put_line fügt zusätzlich ein Zeilenendezeichen an und erhöht 
die Zeilenposition um 1 und setzt die Spaltenposition auf 1. 

put (f,item); 

ist äquivalent zu 

for i ijn item'first .. item'last 
loop 

put (f,item(i)); -- put für CH Ausdruck 
end loop ; 

put_line (f,item); 
ist äquivalent zu 

put (f,item); 
new_line (1); 


11,2.2.2 EIN- BZW. AUSGABE FÜR LOGISCHE WERTE 


Die Prozeduren get und put für logische Werte funktionieren 
wie folgt. 


Syntax: 

Aus 


ADA 54: E/A PROZEDURAUFRUF 


“GED-0— |— 1TF A ~Q~j 


(£ite) 


B VAR —()> 

Utvn) 
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Semantik: 

Vom angegebenen File oder der Standardeingabedatei wird ein 
Name gelesen, dabei wird nicht zwischen Groß- und Kleinbuch¬ 
staben unterschieden. Ist der Name gleich true oder false, 
so wird der entsprechende Wert in itm übergeben, sonst er¬ 
folgt data_error. 

Zeilenendezeichen, Leerzeichen und Tabulatoren werden am An¬ 
fang überlesen. Die Eingabe endet beim 1. Zeichen, das nicht 
der Syntax eines Namens (ADA 65) entspricht. 

Syntax: 

Aus 

ADA 54: E/A PROZEDURAUFRUF 



Semantik: 

Der dem Wert von iXm entsprechende Name (true oder false) 
wird auf ein Ausgabefeld der Breite width - mindestens je¬ 
doch der Länge des Namens - linksbündig geschrieben. Norma¬ 
lerweise in Großbuchstaben; falls lowztijiaA e true ist, je¬ 
doch in Kleinbuchstaben. 

11.2.2.3 EIN- BZW. AUSGABE FÜR GANZZAHLIGE WERTE 

Die Ein- und Ausgabeprozeduren stehen nicht direkt zur Ver¬ 
fügung, sie sind in dem Paketschema integer_io zusammenge¬ 
faßt. Für jeden integer Typ muß aus diesem Schema ein Ein- 
Ausgabepaket erzeugt werden. 
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Syntax: 

Aus 

ADA 11: PAKETERZEUGUNG 


— packaqe - PAK NAME - Ü - new - f:e«tJo. integerJo) -(T)- I TYP 


Name des E/A-Paketes 




£ 


ZUN - ST FKT NAHE 


£ 


ZUN - I FKT NAHE 


^1 


t-cmage) 


Ivatae) 


Semantik: 

Es wird ein Ein-Ausgabepaket für den angegebenen I Typ mm 
erzeugt. 

Der Zuname text_io kann entfallen, falls die Größen des Pa¬ 
ketes text_io durch eine use-Klausel direkt sichtbar gemacht 
wurden. 

Die Funktionen image, und vaZaz beschreiben die Konvertierung 
des Wertes vom integer Typ num zu bzw. von einem String. Als 
Standardvoreinstellung werden hier die attributierten Funk¬ 
tionen num'image und num'value eingesetzt. 

Bei Angabe der Schemaargumente dem Namen nach (num, image 
und value sind die Namen der formalen Schemaargumente) kann 
sich selbstverständlich die Reihenfolge ändern. 

Eine so erzeugte Ausprägung des Schemas integer_io stellt 
die Prozeduren get und put für Werte des integer Typs num 
zur Verfügung. 

Syntax: 

Aus 


ADA 54: E/A PROZEDURAUFRUF 





lltem) 
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Semantik: 

Es wird eine der Syntax entsprechende, gegebenenfalls mit 
einem Vorzeichen versehene integer Literalkonstante gelesen, 
mit Hilfe der Funktion value konvertiert und dem Ausgabear¬ 
gument 'ütd.m zugewiesen. 

Führende Leerzeichen, Tabulatoren und Zeilenendezeichen wer¬ 
den überlesen. Die Eingabe endet beim 1. Zeichen, das nicht 
der Syntax einer integer Literalkonstanten (ADA 39) ent¬ 
spricht. 

Syntax: 

Aus 


ADA 54: E/A PROZEDURAUFRUF 


-Q- j— QTF A ~Q~j 


liile.) 


-I A 

Ufern) 


- j—CD— I A-j-Q-I A—j 


<D- 


Ucidth] (base) 


Semantik: 

put gibt mit der Feldbreite iv+dth (jedoch mindestens alle be¬ 
nötigten Ziffern) rechtsbündig den Wert des Ausdruckes Itm 
in Form einer integer Konstanten ohne Unterstriche und Expo¬ 
nententeil aus. Falls eine Basis =f 10 angegeben wird, so er¬ 
folgt die Ausgabe entsprechend. 


11,2,2.4 EIN- BZW. AUSGABE FÜR GLEITPUNKTZAHLEN 

Die Ein- und Ausgabeprozeduren stehen nicht direkt zur Ver¬ 
fügung, sie sind in dem Paketschema float_io zusammengefaßt. 
Für jeden Gleitpunkttyp muß aus diesem Schema ein Ein-Ausga- 
bepaket erzeugt werden. 
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Syntax: 

Aus 


ADA 11: PAKETERZEUGUNG 


— package - PAK NAHE - i£ - new- (textjo. floatjip -(7)- G TYP 

Mome de 4 erzeugten E/A-Pakete.i 


£ 


ZUN - ST FKT NAHE 


£: 


ZUN - G FKT NAHE 




Semantik: 

Es wird ein Ein/Ausgabepaket für den angegebenen G Typ er¬ 
zeugt. 

Der Zuname text_io kann entfallen, falls die Größen des Pake¬ 
tes text_io durch eine use-Klausel direkt sichtbar gemacht 
werden. 

Die Funktionen imago, und vahie. beschreiben die Konvertierung 
des Wertes vom Gleitpunkttyp num zu bzw. von einem String. 

Als Standardvoreinstellung werden hier die attributierten 
Funktionen num'image und num'value eingesetzt. 

Bei Angabe der Schemaargumente dem Namen nach (num, image 
und value sind die Namen der formalen Schemaargumente) kann 
sich selbstverständlich die Reihenfolge ändern. 

Eine so erzeugte Ausprägung des Schemas float_io stellt die 
Prozeduren get und put für Werte des Gleitpunkttyps num zur 
Verfügung. 


Syntax: 

Aus 

ADA 54: E/A PROZEDURAUFRUF 


-®-p ITF A —Q~| 


l^e) 


G VAR —(j> 

(item) 
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Semantik: 

Es wird eine der Syntax entsprechende, gegebenenfalls mit 
einem Vorzeichen versehene reelle Literal konstante gelesen, 
mit Hilfe der Funktion value konvertiert und dem Ausgabear¬ 
gument Itm zugewiesen. 

Führende Leerzeichen, Tabulatoren und Zeilenendezeichen wer¬ 
den überlesen. Die Eingabe endet beim 1. Zeichen, das nicht 
der Syntax einer reellen Literalkonstanten (ADA 40) ent¬ 
spricht. 


Syntax: 

Aus 

ADA 54: E/A PROZEDURAUFRUF 


-(ED- 


-®- j- OTF A — Q-j 




5 A —|— 1 O— I A —|—O— I A —j—O— I A—| 

nöiiTZJTi’iirZüiHtf fcxfoncnf -kd 


Hantciieiitajige 1 txponent -KD- 


Semantik: 

Der Wert des Gleitpunktausdruckes Itm wird mit widtk Druck¬ 
positionen rechtsbündig ausgegeben: Vorzeichen (falls nega¬ 
tiv), 1. Mantissenstelle, Dezimalpunkt, mantc66a - 1 Mantis- 
senstellen, E, Vorzeichen des Exponenten, Exponent Exponen¬ 
tenziffern. 

Fehlt manti64a 9 so werden num'digits Mantissenstellen ausge¬ 
geben, ist mantissa < num'digits, so wird gerundet, ist 
mantissa > num'digits, so werden führende Nullen vor der 1. 
Mantissenziffer ausgegeben, (num'digits bezeichnet die in 
der Typvereinbarung des Gleitpunkttyps, für den das E/A-Pa- 
ket erzeugt wurde, angegebene Anzahl der dezimalen Mantis- 
senstellen). 

Fehlt ßxpomnt, so werden 2 Exponentenziffern ausgegeben. Es 
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werden mindestens so viele Exponentenziffern ausgegeben, wie 
gebraucht werden. Gegebenenfalls werden führende Nullen ein¬ 
gefügt, um die angegebene Ziffernzahl zu erreichen. 

Eine Konvertierung zu anderen Basen ist nicht vorgesehen. 

Beispiel: Schema zur Ein- und Ausgabe von quadratischen 

Gleitpunktmatrizen beliebiger Dimension 

with text_io; 
generic 

type indextyp is^ (<>); 
type floattyp j_s digits <>; 

type matrix i_s array (indextyp,indextyp) of floattyp; 

package matrix_ea is 

procedure read (a : out matrix); 
procedure write (a : J_n matrix); 
end matrix_ea; 

package body matrix_ea is 
us3 text_io; 

package fio is new float_io (floattyp); 
use fio; 

procedure read (a : out matrix) 
begin 

for i i_n indextyp 
loop 

for j i_n indextyp 
loop 

get (a(i,j)); 
end loop ; 
end loop ; 
end read ; 

procedure write (a : jhi matrix) is 
begin 


for i ijn indextyp 
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loop 

for j jm indextyp 
loop 

put (a(i,j)); 
end loop ; 
newline; 
end loop ; 
end wri te; 
end ; 

Ausprägung dieses Schemas für 2x2-Matrizen vom Typ float 

type matrix is array (integer ränge 1 .. 2, integer ränge 
1 .. 2) of float; 

package mat2_2_ea j_s new matrix_ea (integer ränge 1 .. 2, 
float, matrix); 


11 . 2 . 2.5 EIN- BZW. AUSGABE FÜR FESTPUNKTZAHLEN 


Die Ein- und Ausgabeprozeduren stehen nicht direkt zur Ver¬ 
fügung, sie sind in dem Paketschema fixed_io zusammengefaßt. 
Für jeden Festpunkttyp muß aus diesem Schema ein Ein-Ausgabe- 
paket erzeugt werden. 

Syntax: 

Aus 


ADA 11: PAKETERZEUGUNG 
— P»ckage - PAK NAME " ii - 


i — (text_i o. f i xedilT) - 


F TYP |Q- ZUN - ST FKT NAME -|Q- ZUN - F FKT NAME -<T)-| 


Semantik: 

Es wird ein Ein/Ausgabepaket für den angegebenen Festpunkt¬ 
typ mm erzeugt. 
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Der Zuname text_io kann entfallen, falls die Größen des Pa¬ 
ketes text_io durch eine use-Klausel direkt sichtbar gemacht 
werden. 

Die Funktionen Imago, und valuo. beschreiben die Konvertierung 
des Wertes vom Festpunkttyp num zu bzw. von einem Text. Als 
Standardvoreinstellung werden hier die attributierten Funk¬ 
tionen num'image undnum'value eingesetzt. 

Bei Angabe des Schemaargumentes dem Namen nach (num, image 
und value sind die Namen der formalen Schemaargumente) kann 
sich selbstverständlich die Reihenfolge ändern. 

In dem erzeugten Ein-Ausgabepaket werden die beiden Konstan¬ 
ten delta_image und default_decimals vereinbart. 

delta_image : constant String := image (num'delta - 
integer (num'delta)); 

default_decimals : constant integer := delta_image'length-2; 


Syntax: 

Aus 


ADA 42 ST KONSTANTE (ST KONST) 


- 2UN — (delta_image 

Fe&tpunkt 

Ein -Aulgabepafeef 


Nachpunktdau tettung 
den Schnittweite 


Aus 


ADA 39: I KONSTANTE (I KONST) 


- ZUN - (default declmal?) - 

Fea tpunkt- E/A- Paket 


Anzahl den Nachpunkt- 
stellen den Schnitt¬ 
weite, im Ein/Au&gabe- 
paket 


Semantik: 

delta_image bezeichnet die Stringdarstellung des gebrochenen 
Anteils der Schrittweite delta des Festpunkttyps, für den 
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das E/A-Paket erzeugt wurde, default_decimals beschreibt die 
Anzahl der Nachpunktstellen dieser Schrittweite delta. 

Eine Ausprägung des Schemas fixed_io stellt die Prozeduren 
get und put für Werte des Festpunkttyps num zur Verfügung. 

Syntax: 

Aus 


ADA 54: E/A PROZEDURAUFRUF 



iac») 


Semantik: 

Es wird eine der Syntax entsprechende, gegebenenfalls mit 
einem Vorzeichen versehene reelle Literalkonstante gelesen, 
mit Hilfe der Funktion voIllc. konvertiert und dem Ausgabear¬ 
gument itm zugewiesen. 

Führende Leerzeichen, Tabulatoren und Zeilenendezeichen wer¬ 
den überlesen. Die Eingabe endet beim 1. Zeichen, das nicht 
der Syntax einer reellen Literalkonstante (ADA 40) ent¬ 
spricht. 

Syntax: 

Aus 


ADA 54: E/A PROZEDURAUFRUF 


-®~ p OTF A —Q—| 


F A 


— |—Q—i A -|~C^)— 1 A ~| 


(^£e) 


Fefdb/iei-tc NachpuiiktA-telCai 

Utcj ») Uuidth) (t$*act) 


20 Kaucher IV - ADA 
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Semantik: 

Der Wert des Festpunktausdruckes itm wird mit u)£dtk Ausga¬ 
bepositionen rechtsbündig ausgegeben: Vorzeichen, falls ne¬ 
gativ, ganzzahliger Anteil, Dezimalpunkt, fitiacÄ Nachpunkt¬ 
stellen. Es wird mindestens eine Stelle des ganzzahligen An¬ 
teils ausgegeben. Falls erforderlich, werden führende Nullen 
eingefügt. Fehlt die Angabe von fitiacÄ, so werden die aktuel¬ 
le Stellenzahl default_decimals Nachpunktstellen ausgegeben. 
Ist fi/iact kleiner als default_decimals, so wird gerundet, 
ist fi/iact größer, so werden Nullen angehängt. 


11 . 2 . 2.6 EIN- BZW. AUSGABE efjR WERTE VON 
AUFZÄHLUNGSTYPEN 

Die Ein- und Ausgabeprozduren stehen nicht direkt zur Ver¬ 
fügung, sie sind in dem Paketschema enumeration_io zusammen¬ 
gefaßt. Für jeden Aufzählungstyp muß aus diesem Schema ein 
Ein-Ausgabepaket erzeugt werden. 

Syntax: 

Aus 


ADA 11: PAKETERZEUGUNG 


- pacluge - PAK NAHE - U - new - (text 1o.enumerat1on_i oKD-AZTYP |Q- Z UN - ST FKT NAHE -|Q- ZUN - ! FKT NAHE -(7 


jO-Z 


: ~ 0 -| 


Semantik: 

Es wird ein Ein/Ausgabepaket für den angegebenen Aufzäh¬ 
lungstyp num erzeugt. 

Der Zuname text_io kann entfallen, falls die Größen des Pa¬ 
ketes textio durch eine use-Klausel direkt sichtbar gemacht 
werden. 
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Die Funktionen Image, und value beschreiben die Konvertierung 
des Wertes vom Aufzählungstyp num zu bzw. von einem Text. 

Als Standardvoreinstellung werden hier die attributierten 
Funktionen num'image und num'value eingesetzt. 

Bei Angabe des Schemaarguments dem Namen nach (num, image 
und value sind die Namen der formalen Schemaargumente) kann 
sich selbstverständlich die Reihenfolge ändern. 

Eine so erzeugt Ausprägung des Schemas enumeration_io stellt 
die Prozeduren get und put für Werte des Aufzählungstyps 
num zur Verfügung. 


Syntax: 


Aus 


ADA 54: 

—GH> 


E/A PROZEDURAUFRUF 
ITF A 


tjite) 




AZ VAR -Q> 

Uten 0 


Semantik: 

Es wird eine AZ Literalkonstante gelesen, d.h. entweder ein 
in Apostrophe eingeschlossenes Zeichen oder ein Name, dessen 
interner Wert mit der Funktion value ermittelt und dem Aus¬ 
gabeargument Item zugewiesen wird. 

Syntax: 

Aus 


ADA 54: E/A PROZEDURAUFRUF 


-& -®- |- OTF A —Q-| 


I iile.) 


AZ A 

Utem) 


—|—O — 1 A ~|—O—B A—| 

Iwidth) (lou/e^case) 


<D— 


20* 
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B.ll Ein/Ausgabe 


Semantik: 

Der dem Wert des AZ Ausdrucks itm entsprechende Name wird 
in ein Feld der Breite ivldth linksbündig aus gegeben. Stan¬ 
dardmäßig werden Großbuchstaben verwendet, falls lomn._ca 6e 
den Wert true hat, jedoch Kleinbuchstaben. 

Hinweise: 

Für jeden numerischen Typ muß ein Ein-Ausgabepaket erzeugt 
werden. 

get und put können jeweils nur für einen Wert eines Typs 
verwendet werden. 

Ein/Ausgabe von Aufzählungstypen ist in ADA möglich. 

Für strukturierte Typen lassen sich leicht Ein/Ausgabepakete 
zusammenstellen. 

Die Ausnahmen für das Paketschema input_output haben auch 
für text_io Gültigkeit. 

data_error wird ausgelöst, falls der zu lesende Wert nicht 
der verlangten Syntax entspricht. 

Zusätzlich gibt es noch die Ausnahme 1ayout_error, die aus¬ 
gelöst wird, falls die Spaltenposition auf einen Wert ge¬ 
setzt wird, der größer als die Endposition ist, oder falls 
bei einer Datei fester Zeilenlänge ein Zeilenendezeichen in¬ 
nerhalb einer Zeile gelesen wird. 


11.3 DAS PAKET LOW_LEVEL_IO 

Das Paket low_level_io enthält Prozeduren zum Senden und 
Empfangen von Informationen von bestimmten physikalischen 
Geräten. Für die zur Verfügung stehenden Geräte ist imple¬ 
mentierungsbedingt je eine Prozedur send_control und 
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receive_control anzulegen. 

Syntax: 

ADA 54: E/A PROZEDURAUFRUF 

Aus 

—- (recei ve_control~ > ) —, 

- (send_control ) — KD- GERAET 1 var KD— 

(device) [data) 

Semantik: 

GERAET ist die Bezeichnung eines Objektes von einem imple¬ 
mentierungsabhängigen Gerätetyp. Der Typ T des Ein/Ausgabe¬ 
argumentes data hängt von dem entsprechenden Gerät ab. 


11.4 DER AUSDRUCK FÜR FILES 


Filetypen sind limitierte, geschützte Typen. Es gibt keine 
Standardoperatoren. Man kann Files nicht vergleichen. Vari¬ 
able vom Filetyp wirken wie Konstante, da keine Zuweisung 
möglich ist. Jedoch können Files das Ergebnis von Funktio¬ 
nen und überladenen Operatoren sein (vgl. 3., 5.). 


Syntax: 

ADA 28: T AUSDRUCK (t AUSDR, T A) re« 

♦ - UF.OF.IOF.ITF.OTF) 
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B. 11 Ein/Ausgabe 


Semantik: 

Das Ergebnis eines Ausdruckes ist ein File. Die Wirkung der 
Standarfunktionen wurde in Abschnitt 11.2.1 beschrieben. 

Hinweise: 

Bei der Formulierung von Funktionen mit Ergebnistyp file 
sind alle Einschränkungen zu beachten, die für limitierte, 
geschützte Typen gelten (s. 2.1.6). 
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C. SYNTAXDIAGRAMME 

ADA 1: PROGRAMM 


KONTEXTANGABE — 


vollständige 
liste, den 
Übersetzungs¬ 
einheiten 


Untereinheit 


— separate 


- UNTERPROGRAMM SCHEMA SPEZIFIKATION - 

- PAKET SCHEMA SPEZIFIKATION - 

- UNTERPROGRAMM - 

- UNTERPROGRAMM SPEZIFIKATION - 

- UNTERPROGRAMM ERZEUGUNG - 

- PAKET RUMPF - 


- PAKET SPEZIFIKATION - 

- PAKET ERZEUGUNG - 

-0- ZUN - PGE NAME - 


UNTERPROGRAMM -\ 
PAKET RUMPF - 
L- PROZESS RUMPF 


ADA 2: KONTEXTANGABE 


- with —1— 


•o- 


BIBL E1NH NAME —KD" 


I.O.; 

ise -1— PAK NAME - J -Q- 


with -Klausel 


use-Klattsel 


ADA 3: UNTERPROGRAMM SCHEMA SPEZIFIKATION 

- generic — FOR SCH ARG LISTE — UPG SPEZIFIKATION - 


ADA PAKET SCHEMA SPEZIFIKATION 


generic — FOR SCH ARG LISTE — PAK SPEZIFIKATION - 
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C. SYNTAXDIAGRAMME 


ADA 5: FORMALE SCHEMA ARGUMENT LISTE (FOR SCH ARG LISTE) 

e = (B.CH.AZ.I,G,F,A,ST,REC,Z} ♦ - {IF,OF,IOF,ITF,OTF) e D ■ (B.CH.AZ.l) 

F onmate. A nguminte. &ÜA: 



ADA 6: UNTERPROGRAMM (UPG) 


— UPG SPEZIF - 


-r VtRtlNB IL-1 I * * 

I-L begin -L / 


exceptlon -p AUSN BEHTL 


-j- ftUaN Bbh IL-j 


Ar wciiungit&it 


end 


j PZD NAME —i 

- t FKT NAME - 

- r OPERATOR - 


Un teApto g \amM.ump ^ 


tute in 
UPG SPEZIF 
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ADA 7: UNTERPROGRAMM SPEZIFIKATION (UPG SPEZIF) 

0 = {B,CH,AZ,I,G,F,A,ST,REC,Z) , « - {1F.OF,IOF,ITF,OTF) 



ADA 8: UNTERPROGRAMM ERZEUGUNG 

0 - {B,CH,AZ,I,G,F,A,ST,REC,Z) 


♦ » (1F,0F,I0F,ITF,0TF) 


- procedure — PZD NAME - j_i - new 

- procedure — PZD NAME - li - new 

eeU * Function -r- T OPERATOR -i 

L T PKT NAME -L Ü - new 

functlon — T FKT NAME — li - new 


- ZUN - PZD NAME-AKT SCH ARG LISTE- 

unchecked_deal 1 ocatl on) -(7)— T TYP Z TYP “CD - 
Tshared_var1ab1e_update) -(T)T JYP -(7)- 


- ZUN J T OPERATOR -> 
L t FKT NAME -L 

—(unchecked converslo 


• AKT SCH ARG LISTE - 


Harne eine -s 

entstehenden Schemas 


ADA 9: PAKETRUMPF 


— package - bod* - PAK NAME - li T VEREINBTL 


j VEREINBTL - 


^ ANW ■ 

AIICM DCU TI ■_ 



rri 

i 


- end , PAK NAME 


| KAK NMnt 


Arvoe-isungstei.1 


ADA 10: PAKETSPEZIFIKATION (PAK SPEZIF) 


— package - PAK NAME- js 


1* • VEREINB*: 

i--VEREINB • 

i-DARST ANG-: 

J 

- private -*-- 

J ; 


end 


j PAK NAME 


sichtbanen Teil 
du Paketu 


geschützten. Teil du Paketu 
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C. SYNTAXDIAGRAMME 


ADA 11: PAKETERZEUGUNG 

0 - {B.CII.AZ.l.G.F.A.ST.REC.Zl 



ADA 12: AKTUELLE SCHEMA ARGUMENT LISTE (AKT SCH ARG LISTE) 

0 - {B,CH,AZ,I,G,F,A,ST,REC,Z) » - {IF.OF,IOF,ITF.OTF) 


~lO 


TCP 

T 6 GU* 


.O. 

AKT SCHEMA ARG 

.O. 

t VAR NAME -i 
t TYP NAME - 
— UPG NAME 


- AKT SCHEMA ARG 


W amt du fo/unalen 
Schemaa/igume.ntu 


AktueUz Schtmaasigumentc 

in R tüttniolgt du. io>unalen 
ScJtemamgumente 



in 


btLiebigtA. Rtihtniolgt 


ADA 13: AKTUELLES SCHEMA ARGUMENT (AKT SCHEMA ARG) 

0 - {B,CH,AZ,1,G,F,A.ST,REC,Z) « - {IF,0F.IOF,ITF.OTF) e D - (B.CH.AZ.I) 



A ktuzttu SchcjnaaJigumtnt &ä\: 
Eingabt ( in ) 

Ein-Amgabt lin out ) 

Typ 

PnoztduA. 

Punktion 
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ADA M: PROZESSRUMPF 


— tm-bod* T PZS TYP NAME 


t m ITP NAflt -1 

*- PZS VAR NAME n J VEREINBTL r 

I-L begln -L 


be£«n -L ANW j exceptlon j AUSN BEHTL —, 

I-1-L end PZS VAR NAME n 


PZS TYP NAME - 


ADA 15: PROZESSSPEZIFIKATION 


- task —r- type — PZS TYP NAME -| 

I- PZS VAR NAMF 


- ENTRY VEREINB 


PrvzeMi/pspeziiikation 
Prozeß Spezifikation 


■ PZS TYP NAME 
• PZS VAR NAME 


ADA 16: ENTRY VEREINBARUNG (ENTRY VEREINB) 

G d " (B.CH.AZ.I) 

reo, 

- cntrjr — ENTRY NAME -rL 


INDEX BER —CD - 1 


Verein barung 

einer Familie von indizierten Eingängen 
eines Eingangs 

FOR ARG LISTE —(J )— 


ADA 17: VEREINBARUNGSTEIL (VEREINBTL) 


- VEREINB — 

LI 


nADCT AM r. 


1 


Kumpf-Stumpf 
ats Hinufeis auf 
eine zugehörige 
getrennt über¬ 
setzte Unter¬ 
einheit 


- UNTERPROGRAMM - 

- PAKET RUMPF - 

- PAKET SPEZIFIKATION - 

- PAKET ERZEUGUNG - 

- PROZESS RUMPF - 

- PROZESS SPEZIFIKATION - 

- UNTERPROGRAMM SPEZIFIKATION 


— package - body — PAK NAME - 


lük-bod* — PZS NAME 


Is - separatc 


-KD 
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C. SYNTAXDIAGRAMME 


ADA 18: VEREINBARUNG (VEREINS) e = {b,ch,az,i,g,f,a,st,rec,Z) , « = (if.of.iof.itf.otfj 

e 0 - (B.CH.AZ.I) 
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ADA 19: FORMALE DISKRIMINANTENLISTE (FOR DISKR L) 


e n = (B.CH.AZ.I) 


•©” 


•o- 


■ T DISKR NAME 


r TYP- r-0— t AUSDR 


1 


ADA 20: t TYP DEFINITION (t TYP DEF) t e e u « 

O - (B.CH.AZ.I.G.F.A.ST.REC.Z) . * ■ {IF,OF , IOF,ITF,OTF} 

0 Q =•. (B.CH.AZ.I) 



geschätzte.* Ttjp 
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C. SYNTAXDIAGRAMME 


ADA 21: DATENSATZLISTE (DSL) 

e - (B,CH,AZ,I,G,F,A,ST,REC,Z) i - (1F.0F, IOF,ITF.OTF) Op - (B.CH.AZ.I) 


■Q- 


-•O" 

KOMP NAME —0 


H- 

kr-A) — A 


- r TYP —, 
TYP DEF • 


:rsey—0- r AUSDR 


1 



Auiuxthtaui dtuck 
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ADA 22: T TYP ree u {PZS) u ♦ 

e - (B.CH.AZ.I.G.F.A.ST.REC.Z) , ♦ • {IF,0F,IOF,JTF,OTF) 0 Q = (B.CH.AZ.I) 
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C. SYNTAXDIAGRAMME 


ADA 23: ANWEISUNG (ANW) 

0 - {B.CH.AZ.I.G.F.A.ST.RCC.Z) , « - {IF,OF,1OF.ITF,OTF} 
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ADA 2A: STRUKTURIERTE ANWEISUNG 


e D - (B.CH.AZ.I) 


I 


KttemaXive 

Knnahme- 

anveiiung 


Bedingten 
Eingangi-Kufmi 


I.i I. 

-11 - 1 - B AUSDR — then -L ANW j eise ±- ANW -| 

I-1— end — 1f - 

SCHL NAME -©-> 


ITER KLAUSEL 


1 I.I 

-1— l oop -L ANW — 


l£0£ -i- ANW — end-iooß-p SCHL NAME 


~j~ blHL nATlt —| 


KuitvaJtlauid'utck 


BL NAME 



declare -VFREINBTL 


—l begln l A;M 


exceptlon 


AUSN BEHTL 


n 


end T BL NAME 


A nu/eisungiteil 


1 PL n/ATIL -j 


■ ACCEPT ANWEISUNG ■ 


when - B AUSDR -©- 


Kttz.mcU.ivi oüen, 
&alU tute 


ArrrDT amu . 


nutLri mn 

: 


- dejajf F EINF AUS - 

ANW i 

1.j 

- termlnate - 

O 

. eise -1 ANW -j 

ielect-KltcAJuUive 

L 


L seiect - ZUN ENTRY r AKT ARG LISTE 


t «Kl AKb Llblt -I 

I-Lrr 


© ANW 

{ 



1 * 

or-delay - F EINF AUS -© 

- ANW j 


end-seiect - 


Kuifähnung ialli, Eingangiauimi ioioU 
oder inncnhätb Vexzögexungizeit möglich 


Kuiiühnung,ialls 
Eingang&aui'iui 
nicht möglich 


21 Kaucher IV - ADA 
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C. SYNTAXDIAGRAMME 


ADA 25: ITERATIONSKLAUSEL (ITER KLAUSEL) 

O u = { O ,CH, AZ,I ) 


- for -T VAR NAHE -ln — |— reversc —| 


implizit vexeinbaste 
LaufvasiabEe 


l AUSDR - 


INDEX BER -| 


ADA 26: ACCEPT ANWEISUNG 


— accept — ZUN — ENTRY — FOR ARG LISTE 


Eingang 



Aktionen mährend 
Rendezvous 


- ZUN — ENTRY NAME - 

- ZUN - ENTRY FAM NAHE - 


Name 

b zu. Familienname 
des Eingangs 


I 27: FORMALE ARGUMENTLISTE (FOR ARG LISTE) 

0 ° n3.CH,AZ,l,G.F.A,ST,RF.C,Z) * • (IF.OF.IOF,ITF.OTF) 


T©' 




I.O.; 

| reeu»u(PZ . s jJ T y AR NAME _i_Q_ 


• t TYP 


— out —| 

- in-out —I— r TYP 



ADA 28: T AUSDRUCK (t AUSDR, t A) reeu* 

0 » (O,CH,AZ,I,G,F,A,ST,REC,Z) , ♦ - (IF,OF.IOF,ITF.OTF) 



Oes Exg ebnes typ T ist dusch den 
zuletzt angewendeten Opexatox 
bestürmt. 


Pxioxität I 
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ADA 29: t RELATION (t REL) r e e u ♦ 

e - {8,CH,AZ,I,G,F,A,ST,REC,Z) , ♦ - {IF,OF,IOF , ITF ,OTF) e D « (8,CH,AZ,1) 



ADA 30: r EINFACHER AUSDRUCK (t EINF AUS) t e o u ♦ 

G » {B,CH,AZ,I,G,F,A,ST,REC,ZJ «■ « {IF,OF,IOF,lTF,OTF) 



21* 
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C. SYNTAXDIAGRAMME 


ADA 31: t OPERAND (r OPD) r 6 e u ♦ 

e - (B,CH,AZ,I,G,F,A,ST,REC,Z) 9 - {IF,0F,10F,ITF.OTF} e 0 - (B.CH.AZ.I) 



I 
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ADA 32: AKTUELLE DISKRIMINANTENLISTE (AKT DISKR LISTE) 

e„ « (B.CH.AZ.I) 


•o- 

■ T AUSDR - 


•o- 


.©•••■ 

t DISKR NAME - 


• 0 - t AUSDR - 


A ktuelte Vilknüninanten 
in Reihenfolge den. fonmalen 


in beliebigen. Reihenfolge 


ADA 33: r VARIABLE (t VAR) t e e u (pzs) u « 

0 - {B,CH,AZ,I,G,F,A,ST,REC,Z) , « - {IF.OF,IOF,ITF,0TF) e Q - (B.CH.AZ.I) 



ADA 34: AKTUELLE ARGUMENTLISTE (AKT ARG LISTE) 

0 » (B.CH.AZ.I.G.F.A.ST.REC.Z) , » - (IF.OF,IOF,ITF,OTF) 
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C. SYNTAXDIAGRAMME 


ADA 35: r ATTRIBUTIERTER FUNKTIONSAUFRUF (r ATTR FKT AUFRUF) t e e D u (G.f.st) 

0 Q * (B.CH.AZ.I) 
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ADA 36: B KONSTANTE (B KONST,BOOLEAN KONSTANTE) 



ADA 37: CH KONSTANTE üdiz ,iächitz Szitz 

ADA 38: AZ KONSTANTE (AZ KONST,AUFZAHLUNGSKONSTANTE) 



untere 

obcxe 


Gtenio da AZ Ti/pi 
bzu). I. Indexbe-Kuchcs 
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C. SYNTAXDIAGRAMME 


ADA 37: CH KONSTANTE (CH KONST.CHARACTER KONSTANTE) 


- ZUN - 


-ZEICHEN- Q- 

■ CH KONST NAHE - 

- CH KOMP KONST - 


- CH TYP NAME 

- A TYP NAME 

- A VAR NAME 

- A KONST NAME 


lo. 

1<> 


KÜÜH> 



leilenvouchab [line 
ieed ) 

Vexticat Tab 

Seitenvoxichub Holl 
ieed) 

Uagenxücklaui (cai- 

xiage Ae-tuan) 
Skiit out 

Skiit in 
Vota Link Eicape 
Device Contxol 1 
Device Contxol l 
Device ContAol 3 
Device Contxol 4 
Negative Ackncuiledge 
Synchxonoui Idle 


f<rst> 

last)- 


at_sign~)— 


— (backslast) 


— (clrcumfle) - 


Cancel 

End oi Medium 
Subititute 
Escape, pxeiix 
Fite Sepaxatox 
Gxoup Sepaxatox 
Recoxd Sepaxatox 
Unit Sepaxatox 
Delete 
I 


<1c_a ) 
<1c_b) 
(1c_c ) 
<lc_d> 
- (l c_e~) 

<ic_f) 

<pyy 

- (l c_h") 

<TTT) 

<lc_J ) 

<TTP) 

<1c_1 ) 
Tic nt') 



(1 ex ) 

(JJJ) 


UtexatkoiutaMe 


untexe ] 

> Grenze dei 
obexe ) CH Typs bzu>. 

dei I. Jndex- 
bexeichei 


Kleinbuchitaben 
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ADA 39: I KONSTANTE (I KONST.INTE6ER KONSTANTE) 



Inf ege* Litenalkoni tonte 


Anzahl du Hachpunktiteilen 
de n Schnittueite. im Ein/ 
Auigabepaket 


untere 
o bene 


Grenze, du I Typ * 

bzui. du I. Jndcxbueichu 


Anzahl du ßiti zun Speichenung 
tinu Uentu 

nelativet Ab*tand von du R econd- 
anfang*adtu*e (in Speicheteinheiten ) 

n elativet Abitand du I. bzui. letzten 
Bits von den Anfang*adnu*e den. 
Komponente 


Anzahl den Bin ritt VahAtellung 
einen Uodetlzahl 


Anzahl den dezimalen Uantiuenziffenn 

wie vueinbant 

Anzahl den Mantiuenbiti \ 

| den Uodell- 

gnö/Uen Exponent 
Botin 

Anzahl den Uantiuenbit* 
gnöBten Exponent 
klein*ten Exponent 
Anzahl den Elemente im J. Indexbeneich 


den Masc/ti- 
nenzahlen 


Anzahl du nuuviexten Speichenein¬ 
heiten fit alle Objekte du nefenienten 
Typ* 

Pnionitäx du PnozuiU 

Anzahl den fit die Au*fühnung du 
Ptozuiu benötigten Speicheteinheiten 
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C. SYNTAXDIAGRAMME 


ADA 40: r KONSTANTE (r KONST,GLEITPUNKT KONSTANTE,FESTPUNKT KONSTANTE) 



T € {G»F) 


neelle Litenalkomtante 


Woina-te*! 
gnößten J Uent 
Schnittweite gemäß Veneinbanung 
Schnittweite den. Modellzahlen 
gnäßte Uodellzahl 

kleimten'] 
gnößten } Went 
k leimte ) 

[ poiitive Uodeltzahl 
gnäßte J 

Abitand zwi&chen I und den 
nächitgnößenen Uodellzahl 


ADA Al: A KONSTANTE (A KONST,ARRAY KONSTANTE) 

— ZUN -r- A KONST NAME ■ 


i —A KUlib I NAnt —< 

L A KOMP KONST -L 


ADA 42: ST KONSTANTE (ST KONST,STRING KONSTANTE) 


ZEICHEN • 

b ZUN - ST KONST NAME - 


- ZUN — (delta_1mage^ 


Name de& fentpunkt- 
Ein-Amgabepaketei 


Stning Litenatkomtante 


Hachpunktdam tellung 
den Schnittweite 


ST KOMP KONST 
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ADA 43: t AGGREGAT t e (A,ST) 

0 *> {B,CH,AZ,1,G,F,A,ST,REC,Z} Op • {B.CH.AZ.I) 



Komponenten- KcmponenXemn.rU 

auswahl 


Auflistung den KomponentenuienXe 
in Reihenfolge 


mit Indexangabe 


alten nestlichen Komponenten 


ADA 44: REC KONSTANTE (REC KONST,RECORD KONSTANTE) 


— ZUN 


T 


REC KONST NAME 
REC KOMP KONST 


n 


ADA 45: REC AGGREGAT 

O » {B,CH,AZ,I,G,F ,A,ST,REC , Z) 



Auflistung den Komponentenoexte 
in Reihenfolge 


mit Komponentenname 

atlen neAtlichen Komponenten 


ADA 46: Z KONSTANTE (Z KONST.ZEIGER KONSTANTE) 

—p ZUN — Z KONST NAME 
- Z KOMP KONST - 


ill 


Ventoeis auf keine nefenienXe I /aniable 
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C. SYNTAXDIAGRAMME 


ADA 47: t INDEX BEREICH (t INDEX BER) 

e 0 - (B,CH,AZ,1) 


- T TYP NAHE - ränge 


■ TYP NAHE 
■ t TYP NAHE 


EINF AUS - 


■ r EINF AUS 




untere Grenze 


ADA 48: T KOMPONENTENKONSTANTE (r KOMP KONST) T e e 

0 - {B.CH.AZ.I,G.F,A,ST,REC,Z) e D - {B.CH.AZ.I) 


•o* 


- A KONST 


L©-^r, 


-®-| 


< t-ch y- ST KONST-©- 

-REC KONST —O- 


AUSDR - 
INDEX BEREICH©— 

- I AUSDR-©— 

- r KOMP NAME - 


Komponententyp T 


ADA 49: AUSNAHMEBEHANDLUNGSTEIL (AUSN BEHTL) 



Behandlung von 


ielbitde&inieAten A ui nahmen 


ooxdeiinieAten Km nahmen 


voAdefyinieAten Auinahmen 
bei Ein/Amgabe 


Au&nahmeauMoahl 


Anueliungiteil 
zua Behandlung 
den. Am nähme 


allen Amtlichen Am nahmen 
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ADA 50: DARSTELLUNGSANGABE (DARST ANG) 


- r TYP NAME - 

• PZS NAME 
■ Z TYP NAME 


- use — I AUSDR - 

Bitanzahl \ 


storagesize)- use — J AUSDR - 


SpzlcheA.be.daai o 

- F TYP NAME -(^V- (actua1_deUn) - use -r- G AUSDR 


L -T- b AUbUK — j 

L F AUSDR -L 


Schrittweite 6 


Festlegung der ent¬ 
sprechenden Attribute 
U. ADA 39) 


Umkodierung) 
der inter- l 
neu Varst. ( 
des Al Typ&J 


- for — AZ TYP NAME — use — A AGGREGAT 


Festlegung j 
der Record- > 
darstetlungl 


— for - REC TYP NAME — use - record - 


RECORD DARSTELLUNG 


end 


record - 


l_ for -3ä t KONST NAME 


r VAR NAME- 

— UPG NAME - 

— PAK NAME - 

— PZS NAME - 

— ENTRY NAME - 


| A dresse ■ o 


Adresse du Rumpianiangi • 


Adresse eine* 1 nterruptei * a 


L- use — at — 1 EINF AUS 

liiert a 




ADA 51: RECORD DARSTELLUNG 


__ at_ mod _ I EINF AUS -©-) 



t KOMP NAME - at - I EINF AUS - j^e - I 


EINF AUS -Q- I EINF AUS -Q 1 - 


Position 


iint_bit \ 


last_bit 
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ADA 52: PRAGMA 

dg - (B.CH.AZ.I) 
- pragina —p-f — (wemo ry 


uöikt in den 
P/iogicumeJji- 
heit, in denen 
Veneinba/uwga- 
teit dai 
Pnagma au&tlitt 


Qystem) -Q— NAME-©- 

—(controlled^- 


— f Interface") - CD - 


—(optlmlze 


{storage 


UE) - 1 

_ un * 0 — ' —(T)— 


Speichenptatzbedan{ den Einheit 
I KONST (J ) Inzahl den Böti je Speidieneinheit 
(feeöt Name) 


Ob iektmu chine 


L TYP NAME venhindent automatische Speichenineipabe 


r-O- . 

-0-L UPG NAME HT>- 


Untenpnogname wenden bei Auihuf in den 
Text kopient. 


NAME —0— UPG NAME — (T) ^npno g nanm in andenen Spnadte 


einen Pnognamien- 


& -®r®n 


Zeit- öden Speichenplatzbedani. 


suppress") —(T)-r- (access_checl() -KZ)" 


Untendnücke die 
iotgenden 
Kontnotten: 


- ^dlscriniinantcheck^ -r^T)- 


T 6t bient den 
Zeigern nutz? 


-u- 

Z TYP NAME - 

- Z KONST NAME - 


- Z VAR NAME - 


<D- 


Existient Kom¬ 
ponente iün diene 
Oiikniminante? 


-^index_check^— 


Index innenhalb 
den BeneiduT 


-(Yengthcheck)— 


v 1 

| — l\tv, i i r uniL 

L REC VAR NAME - 

-O. A TVD NAMP —, 


- A KONST NAME - 

- A VAR NAME - 






O- 


länge von fetdenn 
öden Teilen 
konnektT 


—-Ur 


<D- 


I 
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Forts. ADA 52 


I i 
l l 


Eötzu^ügen in 
den betn. Pno- 
zeßbpezi^. 
öden. im ' 
äußern ten 
Veneinbannngb- 
teil du Haupt- 
pnognarmb. 

Ein(ügban wo 
eine Vautet- 
lungtangabe 
btehen kann 


Kamt übenati 

eingeiügt 

wenden. 


(include)— 


—(Vange_check)— 


Index- bzw. Vib- 
kniminantenein- 
bchnänkung zuJtäbbigl 


T6e n U{G.F,A,REC} 

<T)--1- t TYP NAME - 

L t VAR NAME - 


-©- 


storagecheck ) -pCD“ 


Reicht Speichen (,ün 
Aul ^üViung de A 
Funktion new aubt 


— (dlvis i on_check ) 


Vivibion duJich 01 


— (overflowcheck) - (7^- 


{onmateb Mgument on 

■ Z TYP NAME - 

- Z VAR NAME - 

- Z KONST NAME - 




■ T TYP NAME - 


- t KONST NAME - 
r VAR NAME — 


<D- 


— (priori ty) - 


-0— I AUSDR 


legt Pnionität du Pnozubu öden du Hauptpnoqnanrib &ut 


i vonde^inientem Typ pnionity 


-Q-p A TYP NAME —. 

L REC TYP NAME -L®- 


Speichen.ptatupaA.ende Ab&peichenung 


—(T)— ST AUSDR _ (T) Compilen botl hien. dab Textjite einigen. 


Home einu Tentiite 


“©“T“®-1 \ 

L0?>J—©i. 


Compiten holt hien. mit dem Ka^Libten du Pnognamm- 
textu beg-innen Ion) öden auihönen (o^). 


<D- 
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ADA 53: FILEVERWALTUNGSPROZEDURAUFRUF ♦ e (if.of.iof.itf.otf) 


intemei File B extemei Hie a 



eizeugt extemei File a 

oidnel extemei File a internem 
File B zu 

löit die Veibindung zu externem File 
löicht exteinei File 
ietze Leiepoiition auf I. Element 
ietze Schieibpoiition auf I 
ietze Lesepoiition auf y 
ietze Schieibpoiition auf y 
ietze Endpoiition auf y 


ietze Spaltenpoiition auf y 

i dt leibt neue Zeile 
+ v Leeizeilen 


übeilieU Zeile 
+ v Zeilen 


ietze Zeilenlänge auf v (>0) 


B neue Standaidein- 
bzui. auigabedatei 


































































c 
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ADA 54: E/A PROZEDURAUFRUF 

0 - {B,CH,AZ,I,G,F,A,ST,REC,Z> O 0 ■ (B.CH.AZ.I) 



22 Kaucher IV - ADA 
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ADA 55: t E/A STANDARDFUNKTIONSAUFRUF ♦ * Uf.of.iof.itf.otf) 

T 6 {B,I,ST,ITF,OTF) 



I File eröffnet 
Fileende eAAeicht 
Zeilenende eAAeicht 

Zeilenlänge I >01 


Spalten- 


• Position (»öl 


Zeilen- 


vom Typ 
natunal 


> position 


aktuelle Leie- 1 
Sc>t^exi>-j 

Filelänge 
Endposition 
Name des zugeoAdneten externen Fites 


vom Typ 
file_index 


Einlesen eines StAings 


anfängliche 
aktuelle | 
anfängliche 
aktuelle 


StandaAdeingabedatei 


StandaAdausgabedatei 
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ADA 56: ZIFFERNFOLGE (ZF) 

.O.i 


ZIFFER 


ADA 57: ERWEITERTE ZIFFERNFOLGE (EZF) 



ADA 59: PROGRAMMEINHEIT NAME (PGE NAME) 




r- UPG NAME -i 


- PGE NAME - 


- PAK NAME - 


- BLOCK NAME - 


- PZS NAME - 


- SCHL NAME — 



ADA 60: UNTERPROGRAMM NAME (UPG NAME) 


0 0 - (B,CH,AZ,I) 



reou# 


Teeu# 


ree D u{G,F,ST) 




— PZD NAME - 

T FKT NAME - 

t OPERATOR - 

r ATTR FKT NAME - 
- (äbs)- 


{IF,OF,IOF,ITF,OTF} 


22* 
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ADA 61: t OPERATOR reon 

0 » (B.CH.AZ.I.G.F.A.ST.REC.Z) ♦ * {IF ,OF,IOF,ITF.OTF) 



togiichc Optutfoucn 


VeAgldiche. 


AdcUXionin 


dimtcLUge. OpeAatomn 


UuLtiptikationtn 


ExponenUeUion 
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ADA 62: t ATTRIBUTIERTER FUNKTIONSNAME (t ATTR FKT NAME) t e e D u (G.f.st) 

e Q * (B,CH,AZ,I) 



ADA 63: PZS NAME 


n 


PZS TYP NAME - 
PZS VAR NAME 


ADA 64: ENTRY 


e 0 * {B.CH.AZ.n 

ENTRY NAME - 


ENTRY FAM NAME - 


• r AUSDR 



■ 
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ADA 65: NAME 


AUSNAHME NAME 

BIBLIOTHEKS EINHEITS NAME (BIBL EINH NAME) 

BLOCKNAME (BL NAME) 

t DISKRIMINANTEN NAME (t DISKR NAME) r 6 o D 
ENTRY FAMILIEN NAME (ENTRY FAM NAME) 

ENTRY NAME 

r FUNKTIONS NAME (t FKT NAME) r e e u ♦ 

GERAET 

t KOMPONENTEN NAME (r KOMP NAME) r e e u (pzs) u « 

t KONSTANTEN NAME ( T KONST NAME) T e e 

MARKE 

PAKET NAME (PAK NAME) 

PROZEDUR NAME (PZD NAME) 

SCHLEIFEN NAME (SCHL NAME) 

TYP NAME 

t TYP NAME r e e u (PZS) u « 
t VARIABLEN NAME (r VAR NAME) r e e u (pzs) u • 

0 • {B,CH,AZ,1,G,F,A,ST,REC,Z) , « « (IF.OF.IOF,ITF.OTF) 

e D - (B.CH.AZ.I) 


•• BUCHSTABE •*: 

•••• ZIFFER —j-O” 


- BUCHSTABE 


ADA 66: ZEICHEN 


BUCHSTABE 


- ZIFFER 





ADA 67: ZIFFER 


ADA 68: BUCHSTABE 





















D. 

1 . 

ADA 

28 

26 

45 

43 

34 

32 

12 

13 

34 

32 

12 

13 

23 

23 

35 

62 

35 

62 

28 

28 

49 

49 

68 

50 

50 
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VERZEICHNISSE 


VERZEICHNIS DER SYNTAXDIAGRAMME 

NAME BZW. ABKÜRZUNG ref. von ADA 


T A (T AUSDRUCK) 

ACCEPT ANWEISUNG 
REC AGGREGAT 
T AGGREGAT 

AKT ARG LISTE (AKTUELLE ARGUMENTLISTE) 

AKT DISKR LISTE (AKTUELLE DISKRIMINANTEN¬ 
LISTE) 

AKT SCH ARG LISTE (AKTUELLE SCHEMA ARGU¬ 
MENT LISTE) 

AKT SCHEMA ARG (AKTUELLES SCHEMA ARGUMENT) 
AKTUELLE ARGUMENTLISTE (AKT ARG LISTE) 
AKTUELLE DISKRIMINANTENLISTE (AKT DISKR 
LISTE) 

AKTUELLE SCHEMA ARGUMENT LISTE (AKT SCH 
ARG LISTE) 

AKTUELLES SCHEMA ARGUMENT (AKT SCHEMA 
ARG) 

ANW (ANWEISUNG) 

ANWEISUNG (ANW) 


24 

23,48 

31,50 


23,24,31,33 

31 

8,11 

12 


6,9,14,24,26, 


49 


T ATTR FKT AUFRUF (T ATTRIBUTIERTER 
FUNKTIONSAUFRUF) 

T ATTR FKT NAME (T ATTRIBUTIERTER 
FUNKTIONSNAME) 

T ATTRIBUTIERTER FUNKTIONSAUFRUF (T ATTR 31 
FKT AUFRUF) 

T ATTRIBUTIERTER FUNKTIONSNAME (T ATTR 13,18,60 
FKT NAME) 

T AUSDR (T AUSDRUCK) 

T AUSDRUCK (T AUSDR, T A) 5,13,18,19, 

21,23,24,25, 

27,31,32,33, 

34,35,43,45, 


48,50,52,53, 
54,55,64 

AUSN BEHTL (AUSNAHMEBEHANDLUNGSTEIL) 
AUSNAHMEBEHANDLUNGSTEIL (AUSN BEHTL) 6,9,14,24 

BUCHSTABE 65,66 

DARST ANG (DARSTELLUNGSANGABE) 

DARSTELLUNGSANGABE (DARST ANG) 10,15,17 
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21 

21 

54 

55 

30 

30 

64 

16 

16 

57 

57 

53 

27 

19 

5 

27 

19 

5 

65 

47 

47 

25 

25 

48 

48 

41 

38 

36 

37 

39 

44 

42 

40 

46 

41 

38 

36 

37 

39 

44 

42 

40 


D. VERZEICHNISSE 


DATENSATZLISTE (DSL) 

20,21 

DSL (DATENSATZLISTE) 

20,21 

E/A PROZEDURAUFRUF 

23 

T E/A STANDARDFUNKTIONSAUFRUF 

31 

T EINF AUS (T EINFACHER AUSDRUCK) 

T EINFACHER AUSDRUCK (T EINF AUS) 

20,21,22,23, 

24,29,43,47, 

50,51 

ENTRY 

18,23,24,26, 

ENTRY VEREINB (ENTRY VEREINBARUNG) 

ENTRY VEREINBARUNG (ENTRY VEREINB) 

15 

ERWEITERTE ZIFFERNFOLGE (EZF) 

39,40 

EZF (ERWEITERTE ZIFFERNFOLGE) 

39,40 

FILEVERWALTUNGSPROZEDURAUFRUF 

23 

FOR ARG LISTE (FORMALE ARGUMENTLISTE) 

7,16,26 

FOR DISKR L (FORMALE DISKRIMINANTEN- 

5,18 

LISTE) 

FOR SCH ARG LISTE (FORMALE SCHEMA ARGU- 

3,4 

MENTLISTE) 

FORMALE ARGUMENTLISTE (FOR ARG LISTE) 

7,16,26 

FORMALE DISKRIMINANTENLISTE (FOR 

5,18 

DISKR L 

FORMALE SCHEMA ARGUMENTLISTE (FOR SCH 

3,4 

ARG LISTE) 

GERAET 

54 

T INDEX BER (T INDEX BEREICH) 

T INDEX BEREICH (T INDEX BER) 

16,20,21,22, 

24,25,31,33, 

43 

ITER KLAUSEL (ITERATIONSKLAUSEL) 

24 

ITERATIONSKLAUSEL (ITER KLAUSEL) 

24 

T KOMP KONST (T KOMPONENTENKONSTANTE) 

T KOMPONENTENKONSTANTE (T KOMP KONST) 

37,38,39,40, 

41,42,44,46 

A KONST (A KONSTANTE) 

18,31,48 

AZ KONST (AZ KONSTANTE) 

18,31 

B KONST (B KONSTANTE) 

18,31 

CH KONST (CH KONSTANTE) 

18,31 

I KONST (I KONSTANTE) 

18,31 

REC KONST ( REC KONSTANTE) 

18,31 

ST KONST (ST KONSTANTE) 

18,31 

T KONST (T KONSTANTE) 

18,31 

Z KONST (Z KONSTANTE) 

18,31 

A KONSTANTE (A KONST) 

18,31,48 

AZ KONSTANTE (AZ KONST) 

18,31 

B KONSTANTE (B KONST) 

18,31 

CH KONSTANTE (CH KONST) 

18,31 

I KONSTANTE (I KONST) 

18,31,52 

REC KONSTANTE (REC KONST) 

18,31 

ST KONSTANTE (ST KONST) 

18,31,48 

T KONSTANTE (T KONST) 

18,31 


46 

2 

65 

65 

31 

31 

61 

10 

4 

11 

9 

10 

59 

52 

1 

59 

14 

15 

63 

65 

65 

51 

29 

29 

24 

22 

20 

20 

65 

6 

8 

60 

3 

7 

6 


1. Syntaxdiagramme 


Z KONSTANTE (Z KONST) 
KONTEXTANGABE 
MARKE, NAME 
NAME, MARKE, GERAET 


T OPD (T OPERAND) 

T OPERAND (T OPD) 

T OPERATOR 

PAK SPEZIF (PAKETSPEZIFIKATION) 
PAKET SCHEMA SPEZIFIKATION) 
PAKETERZEUGUNG 
PAKETRUMPF 

PAKETSPEZIFIKATION (PAK SPEZIF) 
PGE NAME (PROGRAMMEINHEITSNAME) 
PRAGMA 
PROGRAMM 

PROGRAMMEINHEIT NAME (PGE NAME) 
PROZESSRUMPF 
PROZESSSPEZIFIKATION 
PZS NAME 

PZS TYP NAME 
PZS VAR NAME 
RECORD DARSTELLUNG 
T REL (T RELATION) 

T RELATION (T REL) 

STRUKTURIERTE ANWEISUNG 
T TYP 


T TYP DEF (T TYP DEFINITION) 

T TYP DEFINITION (T TYP DEF) 

T TYP NAME 
UNTERPROGRAMM (UPG) 

UNTERPROGRAMM ERZEUGUNG 
UNTERPROGRAMM NAME (UPG NAME) 
UNTERPROGRAMM SCHEMA SPEZIFIKATION 
UNTERPROGRAMM SPEZIFIKATION (UPG SPEZIF) 
UPG (UNTERPROGRAMM) 
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18,31 

1 

2 , 5 , 6 , 7 , 8 , 9 , 
10,11,12,13, 

14.15.16.17, 
18,19,20,21, 
22,23,24,25, 
26,27,31,32, 
33,34,35,36, 
37,38,39,40, 
41,42,44,45, 
46,47,48,49, 
50,51,52,54, 
58,59,60,62, 
63,64 

30 

30 

6.7.8.13.18, 
60 

1.4.17.18 

1.18 

1.17.18 
1,17 

1.4.17.18 
1,58 


1,58 

1,17 

17,18 

17,18,23,31, 

49.50.59 
14,15,63 
14,15,63 
50 

28 

23 

5,7,8,11,13, 

18,19,20,21, 

27,29 

18,21 

1.17 

1.18 

52.59 
1,18 

1,3,5,6,17,18 
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60 

7 

33 

33 

18 

18 

17 

17 

66 

56 

67 

56 

58 

58 


D. VERZEICHNISSE 


UPG NAME (UNTERPROGRAMM NAME) 

UPG SPEZIF (UNTERPROGRAMM SPEZIFIKATION) 
T VAR (T VARIABLE) 

T VARIABLE (T VAR) 


VEREINB (VEREINBARUNG) 
VEREINBARUNG (VEREINB) 
VEREINBARUNGSTEIL (VEREINBTL) 
VEREINBTL (VEREINBARUNGSTEIL) 
ZEICHEN 

ZF (ZIFFERNFOLGE) 

ZIFFER 

ZIFFERNFOLGE (ZF) 

ZUN (ZUNAME) 

ZUNAME (ZUN) 


13,18,23,31, 

33,34,39,53, 

54 

10,17 

6,9,14,24 

20,37,38,42 

56,57,65,66 

39,40 

1,8,11,13,18, 

20,22,23,24, 

26,31,33,34, 

36,37,38,39, 

40,41,42,44, 

46,49 


2. Wortsymbole 
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2, VERZEICHNIS DER WORTSYMBOLE 

abort ADA 23 
accept ADA 26 
access ADA 20 
all ADA 33 
and ADA 28,61 
array ADA 20 
at ADA 50,51 
begin ADA 6,9,14,24 
body ADA 9,14,17 
case ADA 21,24 
constant ADA 18 
declare ADA 24 
delay ADA 23,24 
delta ADA 5,20,22 
digits ADA 5,20,22 
do ADA 26 
eise ADA 24,28 
elsif ADA 24 

end ADA 6,9,10,14,15,21,24,26,50 
entry ADA 16 

exception ADA 6,9,14,18,24 

exit ADA 23 

for ADA 25,50 

function ADA 7,8 

generic ADA 3,4 

goto ADA 23 

1f ADA 24 

in ADA 5,6,8,25,27,29 

jjs ADA 5,6,8,9,10,11,14,15,17,18,21,24 

limited ADA 5,20 

loop ADA 24 


mod ADA 30,51,61 
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new ADA 8,11,20,31 

not ADA 29,30,61 

null ADA 21,23,46 

of ADA 20 

or ADA 24,28,61 

others ADA 21,24,43,45,49 

out ADA 5,27 

package ADA 9,10,11,17,18 

pragma ADA 52 

private ADA 5,10,20 

procedure ADA 7,8 

raise ADA 23 

ränge ADA 5,20,22,47,51 

record ADA 20,50 

rem ADA 30,61 

renames ADA 18 

return ADA 7,23 

reverse ADA 25 

select ADA 24 

separate ADA 1,17 

subtype ADA 18 

task ADA 14,15,17,18 

terminate ADA 24 

then ADA 24,28 

type ADA 5,15,18 

use ADA 2,18,50 

when ADA 21,23,24,49 

while ADA 25 


xor ADA 28,61 
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3. VERZEICHNIS DER STANDARDNAMEN 


(in Ovale eingeschlossene Buchstabenfolgen) 


Bei der nachfolgenden Angabe der Gruppen wurden folgende Ab¬ 
kürzungen verwendet: 


A Attribut 
Aus Ausnahme 
K Konstante 
P Pragma 


Pak Paket 
SF Funktion 

SP Prozedur 

T Typ 


Name 

Gruppe 

Diagramm 

abs 

SF 

ADA 31,60 

ack 

K 

ADA 37 

actual delta 

A 

ADA 40,50 

address 

A 

ADA 31 

ascii 

Pak 

ADA 37 

at sign 

K 

ADA 37 

backslash 

K 

ADA 37 

bar 

K 

ADA 37 

base 

A 

ADA 22,35,36,37,38,39,40,62 

bei 

K 

ADA 37 

bi ts 

A 

ADA 39 

boolean 

T 

ADA 22 

bs 

K 

ADA 37 

can 

K 

ADA 37 

character 

T 

ADA 22 

circumflex 

K 

ADA 37 

close 

SP 

ADA 53 

col 

SF 

ADA 55 

constrained 

A 

ADA 36 

constraint error 

Aus 

ADA 49 

controlled 

P 

ADA 52 

count 

A 

ADA 31 

er 

K 

ADA 37 

create 

SP 

ADA 55 

currentj'nput 

SF 

ADA 55 

current output 

SF 

ADA 55 

data error 

Aus 

ADA 49 

dcl 

K 

ADA 37 

dc2 

K 

ADA 37 

dc3 

K 

ADA 37 

dc4 

K 

ADA 37 
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de fault decimals 

K 

ADA 39 

de! 

K 

ADA 37 

delete 

SP 

ADA 53 

del ta 

A 

ADA 40 

delta image 

K 

ADA 42 

device_error 

Aus 

ADA 49 

digits 

A 

ADA 39 

die 

K 

ADA 37 

dollar 

K 

ADA 37 

duration 

T 

ADA 22 

em 

K 

ADA 37 

emax 

A 

ADA 39 

end error 

Aus 

ADA 49 

end of file 

SF 

ADA 55 

end_of line 

SF 

ADA 55 

enq 

K 

ADA 37 

eot 

K 

ADA 37 

epsilon 

A 

ADA 40 

esc 

K 

ADA 37 

etb 

K 

ADA 37 

etx 

K 

ADA 37 

exclam 

K 

ADA 37 

failure 

A 

ADA 49 

false 

K 

ADA 36,49 

ff 

K 

ADA 37 

file index 

T 

ADA 22 

first 

A 

ADA 35,36,37,38,39,40,62 

first_bit 

A 

ADA 39 

fixed io 

Pak 

ADA 11 

float 

T 

ADA 22 

float io 

Pak 

ADA 11 

fs “ 

K 

ADA 37 

get 

SP 

ADA 54 

get line 

SF 

ADA 55 

get string 

SF 

ADA 55 

gs 

K 

ADA 37 

grave 

K 

ADA 37 

ht 

K 

ADA 37 

image 

A 

ADA 35,62 

include 

P 

ADA 52 

in!ine 

P 

ADA 52 

inout file 

T 

ADA 22 

input_output 

Pak 

ADA 11 

integer 

T 

ADA 22 

integer io 

Pak 

ADA 11 

interface 

P 

ADA 52 

i n_f i 1 e 

T 

ADA 22 

is_open 

SF 

ADA 55 

large 

A 

ADA 40 

last 

A 

ADA 35,36,37,38,39,40,62 


SF 

ADA 55 
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1ast_bit 

layout_error 

lc_a 

1 c_z 

length 

lf 

1 ine 

line_length 
1 ist 

long_float 

long_integer 

l_brace 

l_bracket 

machine_emax 

machine_emin 

machine_mantissa 

machine_overf 1 ows 

machine_radix 

machine_rounds 

mantissa 

maxjint 

memory_size 

min_int 

nak 

name 

name_error 
natural 
new_line 
nex t_read 
next_wri te 
nul 

numeric_error 

open 

optimize 
outfile 
pack 
pos 

Position 

pred 

priori ty 
put 

put_l ine 
que ry 
ränge 
read 

receive_control 
reset read 


A 

ADA 39 

Aus 

ADA 49 

K 

ADA 37 

K 

ADA 37 

A 

ADA 35,39,62 

K 

ADA 37 

SF 

ADA 55 

SF 

ADA 55 

P 

ADA 52 

T 

ADA 22 

T 

ADA 22 

K 

ADA 37 

K 

ADA 37 

A 

ADA 39 

A 

ADA 39 

A 

ADA 39 

A 

ADA 39 

A 

ADA 39 

A 

ADA 36 

A 

ADA 39 

K 

ADA 39 

K 

ADA 39 

P 

ADA 52 

K 

ADA 39 

K 

ADA 37 

SF 

ADA 55 

Aus 

ADA 49 

T 

ADA 22 

SP 

ADA 53 

SP 

ADA 55 

SP 

ADA 55 

K 

ADA 37 

Aus 

ADA 49 

SP 

ADA 53 

P 

ADA 52 

T 

ADA 22 

P 

ADA 52 

A 

ADA 35,62 

A 

ADA 39 

A 

ADA 35,62 

T 

ADA 39,22 

P 

ADA 52 

SP 

ADA 54 

SP 

ADA 54 

K 

ADA 37 

A 

ADA 22 

SP 

ADA 54 

SP 

ADA 54 

SP 

ADA 53 
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reset write 

SP 

ADA 53 

rs 

K 

ADA 37 

r brace 

K 

ADA 37 

r bracket 

K 

ADA 37 

select error 

Aus 

ADA 49 

send_control 

SP 

ADA 54 

set col 

SP 

ADA 53 

set_input 

SP 

ADA 53 

set line length 

SP 

ADA 53 

set_output 

SP 

ADA 53 

set read 

SP 

ADA 53 

set_write 

SP 

ADA 53 

shared variable update 

SP 

ADA 8 

sharp 

K 

ADA 37 

short_float 

T 

ADA 22 

short integer 

T 

ADA 22 

si 

K 

ADA 37 

size 

A 

ADA 39,50 


SF 

ADA 55 

skip line 

SP 

ADA 53 

smalT 

A 

ADA 40 

so 

K 

ADA 37 

soh 

K 

ADA 37 

Standard input 

SF 

ADA 55 

standard_output 

SF 

ADA 55 

Status error 

Aus 

ADA 49 

storage error 

Aus 

ADA 49 

storage size 

A 

ADA 39,50 

storage_unit 

P 

ADA 52 


K 

ADA 39 

string 

T 

ADA 22 

stx 

K 

ADA 37 

sub 

K 

ADA 37 

succ 

A 

ADA 35,62 

suppress 

P 

ADA 52 

syn 

K 

ADA 37 

System 

Pak 

ADA 39 


P 

ADA 52 

tasking error 

Aus 

ADA 49 

terminated 

A 

ADA 31 

text.io 

Pak 

ADA 11 

ti 1 de 

K 

ADA 37 

true 

K 

ADA 36 

truncate 

SP 

ADA 53 

unchecked conversion 

SF 

ADA 8 

unchecked deallocation 

SP 

ADA 8 

US 

K 

ADA 37 

use error 

Aus 

ADA 49 

val 

A 

ADA 35,62 

val ue 

A 

ADA 35,62 

vt 

K 

ADA 37 

write 

SP 

ADA 54 
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4. DAS ADA-WÖRTERBUCH 

Syntaxvariable im Übersetzung Diagramm- 

Reference Manual (falls vorgenommen) Nr. 


A 


abort Statement 

abnormale Terminierung 

ADA 

23 

accept Statement 

ACCEPT ANWEISUNG 

ADA 

26 

access type definition 

Z TYPDEFINITION 

ADA 

20 

accuracy constraint 

Genauigkeitseinschränkung 

ADA 

20 

actual parameter 

aktuelles Argument 

ADA 

34 

actual parameter part 

aktuelle Argumentliste 

ADA 

34 

adding operator 

Additionsoperator 

ADA 

30 

address specification 

Adreßangabe 

ADA 

50 

aggregate 

T AGGREGAT 

ADA 

43,45 

alignment clause 


ADA 

51 

allocator 

Spei cherbelegungsfunktion 

ADA 

31 

argument 

Argument 

ADA 

52 

array type definition 

A TYPDEFINITION 

ADA 

20 

assignment Statement 

Wertzuweisung 

ADA 

23 

attribute 

ATTRIBUTIERTER FUNKTIONS¬ 

ADA 31/ 


AUFRUF oder attributierte 

35,. 

..,40 


T KONSTANTE 



B 

base 

Basis (eines Zahlsystems) 

ADA 

40 

based integer 

ERWEITERTE ZIFFERNFOLGE 

ADA 

57 

based number 

Basisbezogene Zahl 

ADA 

40 

basic loop 


ADA 

24 

block 

Block 

ADA 

24 

body 

Rumpf 

ADA 

17 

body stub 

Rumpfstumpf 

ADA 

17 

c 

case Statement 

Auswahlanweisung 

ADA 

24 

character literal 

Zeichenliteral 

ADA 

37 


23 Kaucher IV - ADA 
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character string 

Zeichenkette 

ADA 42 

choice 

Auswahl 

ADA 21 

code Statement 

Code Anweisung 

ADA 23 

Compilation 

PROGRAMM 

ADA 1 

Compilation unit 

Übersetzungseinheit 

ADA 1 

component association 


ADA 43,45 

component declaration 

Komponentenvereinbarung 

ADA 21 

component list 

DATENSATZLISTE 

ADA 21 

compound Statement 

STRUKTURIERTE ANWEISUNG 

ADA 24 

condition 

Bedingung 

ADA 28 

conditional entry call 

Bedingter Eingangsaufruf 

ADA 24 

constraint 

Einschränkung 

ADA 22 

context specifi cation 

KONTEXTANGABE 

ADA 2 

D 

decimal number 

Dezimal zahl 

ADA 39,40 

declaration 

VEREINBARUNG 

ADA 18 

declarative item 

VEREINBARUNG 

ADA 18 

declarative part 

VEREINBARUNGSTEIL 

ADA 17 

delay Statement 

Verzögerungsanweisung 

ADA 23 

derived type 

Definition eines abgelei¬ 

ADA 20 

definition 

teten Typs 


designator 

UNTERPROGRAMMNAME 

ADA 60 

discrete ränge 

INDEXBEREICH 

ADA 47 

descriminant 

AKTUELLE DISKRIMINANTEN¬ 

ADA 32 

constraint 

LISTE 


discriminant 


ADA 32 

declaration 



discriminant part 


ADA 32 

discriminant 


ADA 32 

specifi cation 



E 

entry call 

Eingangsaufruf 

ADA 23 

entry declaration 

ENTRY VEREINBARUNG 

ADA 16 
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enumeration literal 

AZ KONSTANTE 

ADA 38 

enumeration type 

AZ TYPDEFINITION 

ADA 20 

defini tion 



enumeration type 

Aufzählungstypdarstel1ung 

ADA 50 

representation 



exception choice 

Ausnahmeauswahl 

ADA 46 

exception declaration 

Ausnahmevereinbarung 

ADA 18 

exception handler 

Ausnahmebehandler 

ADA 46 

exit Statement 

Sprung aus Schleife 

ADA 23 

exponent 

Exponent 

ADA 40 

exponentiating 

Exponentiationsoperator 

ADA 30 

operator 



expression 

AUSDRUCK 

ADA 28 

extended digit 


ADA 57 

F 

factor 


ADA 30 

fixed point constraint 

F TYPDEFINITION 

ADA 20 

floating point 

G TYPDEFINITION 

ADA 20 

constraint 



formal parameter 

formales Argument 

ADA 27 

formal part 

FORMALE ARGUMENTLISTE 

ADA 27 

function call 

Funktionsaufruf 

ADA 31,33 

G 

generic actual para¬ 

AKTUELLES SCHEMAARGUMENT 

ADA 13 

meter 



generic association 


ADA 12 

generic formal para¬ 

Formales Schemaargument 

ADA 5 

meter 



generic instantiation 

Ausprägung, Erzeugung 

ADA 8,11 

generic package 

PAKETSCHEMAVEREINBARUNG 

ADA 4 

declaration 



generic package 

PAKETERZEUGUNG 

ADA 11 


instantiation 


23* 
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generic part 


ADA 3,4 

generic subprogram 

UNTERPROGRAMM SCHEMA 

ADA 3 

declaration 

VEREINBARUNG 


generic subprogram 

UNTERPROGRAMMERZEUGUNG 

ADA 8 

instantiation 



generic type defini- 


ADA 5 

tion 



goto Statement 

Sprunganweisung 

ADA 23 

I 

identifier 

NAME 

ADA 65 

identifier list 


ADA 18 

if Statement 

Bedingte Anweisung 

ADA 24 

imcomplete declaration 

Unvollständige Typverein- 

ADA 18 


barung 


index 

Index (eines Feldes) 

ADA 20 

index constraint 

Indexeinschränkung 

ADA 20,31 

indexed component 

Feldkomponente 

ADA 33 

integer 

ZIFFERNFOLGE (ZF) 

ADA 56 

integer type defini - 

I TYPDEFINITION 

ADA 20 

tion 



iteration clause 

ITERATIONSKLAUSEL 

ADA 25 

L 

label 

Marke 

ADA 23 

length specification 

Längenangabe 

ADA 50 

letter 

BUCHSTABE 

ADA 68 

1 etter or digit 



1 i teral 

Literalkonstante 

ADA 38,39 



40,42,46 

lo ca tion 

Speicherplatz (einer 

ADA 51 


Recordkomponente) 


logical operator 

logischer Operator 

ADA 28 

loop parameter 

Laufvariable 

ADA 25 

loop Statement 

Wiederholungsanweisung 

ADA 24 

lower case letter 

Kleinbuchstabe 

ADA 68 
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M 

mode Argumentübergabemodus ADA 27 

multiplying operator Multiplikationsoperator ADA 30 


N 

name VARIABLE oder ADA 33, 

attributierte Konstante 36,..,40 


null Statement 

Leere Anweisung 

ADA 23 

number declaration 


ADA 18 

numeric literal 

numerische Literaikon¬ 

ADA 39,40 


konstante 



0 


object declaration 

Variablen-bzw. Konstan¬ 
tenvereinbarung 

ADA 18 

operator symbol 

OPERATOR 

ADA 61 


p 


package body 

PAKETRUMPF 

ADA 9 

package declaration 

Paketvereinbarung 

ADA 

package specification 

PAKETSPEZIFIKATION 

ADA 10 

Parameter association 


ADA 34 

Parameter declaration 


ADA 27 

pragma 

PRAGMA 

ADA 52 

pri ma ry 

OPERAND 

ADA 31 

private type defini- 

Definition eines ge¬ 

ADA 20 

tion 

schützten Typs 


procedure call 

Prozeduraufruf 

ADA 23 

program component 


ADA 17 

qualified expression 

Qualifizierter Ausdruck 

ADA 31 


R 


raise 

Statement 

Ausnahmeauslösung 

ADA 

23 

ränge 


Bereich 

ADA 

20, 

47 

ränge 

constraint 

Bereichseinschränkung 

ADA 

20, 

47 
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real type definition 

R TYPDEFINITION 

ADA 20 

record type definition 

REC TYPDEFINITION 

ADA 20 

record type represen- 

Recorddarstellung 

ADA 51 

tation 



relation 

RELATION 

ADA 29 

relational operator 

Vergleichsoperator 

ADA 29 

renaming declaration 

Umbennung 

ADA 18 

representation speci- 

DARSTELLUNGSANGABE 

ADA 50 

fication 



return Statement 

Unterprogrammrücksprung 

ADA 23 

S 

select alternative 

select-Alternative 

ADA 24 

selected component 



select Statement 

alternative Annahme- 

ADA 24 


anweisung 


selective wait 

alternative Annahme¬ 

ADA 24 


anweisung 


sequence of State¬ 

Anweisungsfolge 

ADA 6,9, 

ments 


14,24,26 

simple expression 

EINFACHER AUSDRUCK 

ADA 30 

sl ice 

Vektorabschnitt 

ADA 33 

Statement 

ANWEISUNG 

ADA 23 

subprogram body 

UNTERPROGRAMM 

ADA 6 

subprogram declaration 


ADA 1 

subprogram specifi¬ 

UNTERPROGRAMMSPEZI- 

ADA 7 

cation 

FICATION 


subtype declaration 

Untertypvereinbarung 

ADA 18 

subtype indication 

TYP 

ADA 22 

subunit 

Untereinheit 

ADA 1 

subunit body 


ADA 1 

T 

task body 

PROZESSRUMPF 

ADA 14 

task declaration 

PROZESSPEZIFIKATION 

ADA 15 

task specification 

PROZESSPEZIFIKATION 

ADA 15 
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term 


ADA 30 

timed entry call 

verzögerter Eingangs- 

ADA 24 


aufruf 


type conversion 

Typkonversion 

ADA 31 

type declaration 

Typvereinbarung 

ADA 18 

type definition 

TYPDEFINITION 

ADA 20 

type mark 

TYP NAME 

ADA 22,35 

U 

unary operator 

einstelliger Operator 

ADA 30 

underscore 

Unterstrich 


upper case letter 

Großbuchstabe 

ADA 68 

use clause 

use-Klausel 

ADA 2 

V 



variant part 

Variantenteil 

ADA 21 

with clause 

with-Klausel 

ADA 2 
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5, STICHWORTVERZEICHNIS 


A 

Anweisung(-s) 

-, Annahme- B.9.2.3, ADA 26 
abort - B.9.5, ADA 23 
accept- B.4.11,B.9.2.3, ADA 26 
-, Auswahl- B.4.8 
-, bedingte B.4.4 
case - B.4.8 
-, code- B.4.13 
-, delay- B.9.4, ADA 23 
-, Ein- bzw. Ausgabe- B.4.3, B.ll 
-, exit- B.4.5 
-, goto - B.4.6 
-, leere B.4.1 

-, raise - B.4.12, B.7.3, ADA 23 
-, return - B.4.7, B.2.5, ADA 23 
-, select - B.9.3 
-, Sprung- B.4.6 
-, strukturierte B.4 
- teil B.4, ADA 29 
-, terminate- B.9.5, ADA 23 
-, Wiederholungs- B.4.5 

-, zur Syndronisierung von Prozeduren B.4.11 
abgeleiteter Typ B.2.1.5, ADA 20 
Abhängigkeit eines Prozessors B.9 
Akürzungen von Typen B.2.1 
Abortanweisung B.9.5, ADA 23 
accept-Anweisung B.2.6, B.9.2.3, ADA 26 
Adreßangabe B.8.2.4, ADA 50 
Aggregat B.3.6, B.3.7, ADA 43, ADA 45 
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Aktivierung eines Prozessors B.9.1 
aktuelle(-s) 

- Argument(-Liste) B.2.5, B.5.6, ADA 34 

- Schemaargument B.2.5, B.6.3, ADA 13 

- Schemaargument Liste B.2.5, B.6.3, ADA 12 
Alphabet A.2., A.2.1 

Alternative B.4.4, ADA 24 

- accept -Anweisung B.4.11 

-, geschlossene B.9.3 

-, offene B.9.3, B.9.4 

-, terminate - B.9.3 

Anfangswert B.2.2, ADA 19, ADA 21 

Annahmeanweisung B.9.2.3, ADA 26 

Anonymer Typ B.2.1.1.1.4 

Argument B.l.l 

-, aktuelles B.5.6, ADA 34 

-, aktuelles Schema- B.6.3, ADA 13 

-, Ausgabe- B.5.1, ADA 27 

-, formales B.5, ADA 22 

-, formales Schema- B.6.1, ADA 5 

Argument!iste 

-, aktuelle B.5.6, ADA 34 

-, aktuelle Schema- B.6.3, ADA 12 

-, formale B.5, ADA 27 

-, formale Schema- B.6.1, ADA 5 

Array 

- ausdruck B.3.6, ADA 28 
-, dynamisch B.2.1.2.1 

- typ B.2.1.2.1 

- variable B.2.2 

Attribute B.2.1.5, B.3.11, ADA 35,36,38,39,40,50 
-, Prozeß- B.9.8 
Aufruf B.l.l 

-, bedingter Eingangs- B.4.11, B.9.3, ADA 24 
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- einer Funktion B.2.1.5, B.5.4, ADA 31 

- einer Prozedur B.2.1.5, B.4.10, B.5.3, ADA 23 

- eines Operators B.2.1.5, B.5.5, ADA 28, 29, 30 
-, verzögerter Eingangs- B.4.11, B.9.4, ADA 24 
Aufzählungs 

- typ B.2.1.1.1.1, ADA 20 

- darstellung B.8.2.2, ADA 50 

- konstante + Konstante ADA 38 
Ausdruck . B.3, ADA 28 

-, Auswahl- B.4.8 

- für Fehler B.3.6, ADA 28 

- für Files B.11.4, ADA 28 

- für Zeichenketten B.3.6.3, ADA 28 

- für Zeiger B.3.8, ADA 28 
-, ganzzahliger B.3.4, ADA 28 
-, logischer B.3.1, ADA 28 

-, Record- B.3.7, ADA 28 
-, reeller B.3.5, ADA 28 
-, statischer B.3. 

- vom Aufzählungstyp B.3.3, ADA 28 
-, Zeichen- B.3.2, ADA 28 

Ausführung eines Programmes B.l, B.l.l, B.10.4 
Ausgabe 

- anweisung B.4.3, B.ll, ADA 54 

- argument B.l.l, B.5.1, ADA 5, ADA 27 
-, Ausnahmen bei B.ll.3, ADA 46 

- file B.ll.1.1, B.ll.2.1, ADA 22 

- für Festpunktzahlen B.11.2.2.5, ADA 54 

- - ganzzahlige Werte B.11.2.2.3, ADA 54 

- - Gleitpunktzahlen B.11.2.2.4, ADA 54 

- - logische Werte B.11.2.2.2, ADA 54 

- - Werte von Aufzählungstypen B.11.2.2.6, ADA 54 

- - Zeichen und Zeichenketten B.11.2.2.1, ADA 54 
-, Standardfunktion für B.ll, ADA 55 
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-, Standardprozeduren für B.ll, ADA 54 
Auslösen einer Ausnahme B.4.12, B.7.3, ADA 23 
Ausnahme(-n) B.2, B.4.12, B.7 
Auslösen einer B.7.3, ADA 23 

- bei Ein- bzw. Ausgabe B.11.3, ADA 46 

- behandler B.7.4 

- behandlung B.7 

- - teil B.7.4, ADA 46 

- Verbreitung B.7. 5 

- Vereinbarung B.2.7, B.7.2, ADA 18 
-, vordefinierte B.7.1, ADA 46 
Ausprägung von Schemata B.6.2 
Auswahl B.4.8, ADA 24 

- anweisung B.4.8, ADA 24 

- ausdruck B.2.1.1.2,B.4.8, ADA 21, ADA 24 

- marke B.2.1.2.2, ADA 21 

- typ B.4.8 

Auswertung eines Ausdruckes B.3 

B 

Basis typ B.2.1, ADA 20 
bedingte Anweisung B.4.4, ADA 24 
Bezeichner A.2.2.1 
Bibliothekseinheit B.l, B.10.1 
Block B.2, B.4.9, ADA 24 

- name B.4.9, ADA 24 

- Schachtelung B.10 
boolean B.2.1.1.1.2, ADA 22 

- Konstante •* Konstante ADA 36 
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C 

case -Anweisung B.4.8, ADA 24 
character B.2.1.1.1.3, ADA 22 

- Konstante -* Konstante ADA 37 
Compilerinstruktionen B.8, ADA 50, ADA 52 

D 

Darstellung(-s) B.8.2 

-, angabe B.2, B.2.15, B.8.2, ADA 50 

-, Aufzählungstyp- B.8.2.2, ADA 50 

- höherer Sprachen A.2 

-, Record- B.8.2.3, ADA 51 
Datei (-> File) B.ll 
Daten 

- Objekte B.2.1 

- satzliste B.2.1.2.2, ADA 21 

- typen B.1.2 

delay-Anweisung B.9.4, ADA 23 
Diagramme A.2.1.1 

diskreter Typ B.2.1.1.1, B.2.1.2.1, ADA 5 
Diskrimmiante B.2, B.2.1.2.2, ADA 21, ADA 22 
Direktive B.8.1, ADA 52 
direkt sichtbar B.10.3 
Disjunktion B.3.1, ADA 61 
Durchlauf, durchlaufen A.2.2.1 
duration B.2.1.1.2.2, B.10.1.3 
dynamisches Array B.2.1.2.1 

- variable + Zeiger 


E 

Eingabe B.ll 

- anweisung B.4.3, B.ll, ADA 54 

- argument B.l.l, B.5.1, B.6.1, ADA 5, ADA 27 
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Ausnahme bei - B.11.3, ADA 46 

- file B.11.2.1, B.11.2.1, ADA 22 

- für Festpunktzahlen B.11.2.2.5, ADA 54 

- - ganzzahlige Werte B.11.2.2.3,ADA 54 

- - Gleitpunktzahlen B.11.2.2.4,ADA 54 

- - logische Werte B. 11.2.2.2, ADA 54 

- - Werte von Aufzählungstypen B.1.2.2.6, ADA 54 

- - Zeichen und Zeichenketten B.11.2.2.1, ADA 54 

-, Standardfunktionen für B.ll, ADA 55 

-, Standardprozeduren für B.ll, ADA 54 
Ein-/Ausgabe (-* Eingabe, -*■ Ausgabe) 

- argument B.5.1, B.6.1, ADA 5, ADA 27 

- file B.ll.1.1, ADA 22 
Eingang(s) B.2, ADA 16 

- aufruf B.9.2.2, ADA 23 

- aufruf, bedinger B.9.3, ADA 24 

- aufruf, verzögerter B.9.4, ADA 24 
-, indizierter B.2, ADA 16 

- Vereinbarung B.9.2.1, ADA 16 

- warteschlange B.9.2.4 
entry- Vereinbarung B.9.2.1, ADA 16 
Erzeugung 

- Paket B.6.2, ADA 11 

- Unterprogramm B.6.2, ADA 8 
exit - Anweisung B.4.5, ADA 23 
Exponentiation B.3.4, B.3.5, ADA 30 

F 

Feld -* Array 

fester Teil B.2.1.2.2, ADA 21 
Festpunkt 

- ausdruck B.3.5.2, ADA 28 

- Konstante -*■ Konstante ADA 40 

- typ B.2.1.1.2.2, ADA 20, ADA 22 
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File(-s) B.ll.l 

-, aktuelle Länge eines - B.11.1.1 
-, - Leseposition eines - B.11.1.1 
-, - Schreibposition eines - B.11.1.1 
-, Ausgabe - B.11.1.1, B.11.2.1, ADA 22 
-, Ausdruck für B.11.4 
-, Endposition eines - B.11.1.1 

- index B.2.1.1.1.4, ADA 22 
Text- B.11.2 

-, typ B.11.1.1, ADA 22 
Verwaltung B.11.1.1 

- - Prozeduren B.11.1.1, ADA 53 
float B.2.1.1.2.1, ADA 22 
for-Klausel B.4.5, ADA 25 
formale(-s) 

- Argument(-Liste) B.l.l, B.5, ADA 27 

- Schemaargument(-Liste) B.6.1, ADA 5 
Funktion(-s)(+ Unterprogramm) B.5, ADA 7 

- aufruf B.5.4, ADA 31 


G 

ganzzahlige(r) 

- Division B.3.4 

- Rest B.3.4 

- Konstante ADA 36 

generische Programmeinheit (+ Schema) B.6 
geschützter Typ B.2.1.6, ADA 10, ADA 20 
gleichrangig B.3 
Gleitpunkt 

- ausdruck B.3.5 ADA 28 

- konstante -* Konstante ADA 40 

- typ B.2.1.1.2.1, ADA 20, ADA 22 
globale Größe B.10.5 
goto-Anweisung B.4.6, ADA 23 
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Grammatik A.2.2 
Größe B.2 
-, globale B.10.5 
-, lokale B.10.5 

Gültigkeitsbereich eines(r) B.10.2, B.10.5 

- Diskriminante 

- Eingangs 

- formalen Argumentes 

- getrennt übersetzten Paketes 

- getrennt übersetzten Unterprogrammes 

- Größe eines Programmes 

- Literais eines Aufzähltyps 

- Recordkomponente 

- Schleifenparameters (Laufvariable) 

i 

I Konstante ADA 39 
implizit vereinbart B.2 
Index B.2.1.2.1 

- bereich B.2.1.2.1, B.2.1.1.1.4, ADA 20 

- bereichstyp B.2.1.1.1.4, ADA 22 

- grenze B.2.1.2.1 

- typ Komponententyp B.2.1.1.1.4 
Initialisierung B.2.1.2.1, B.2.1.2.2, B.2.2, ADA 18 
input-output Paketschema B.ll.l 

integer B.2.1.1.1.4 ADA 22 

- Konstante *> Konstante ADA 39 
-, universal_ B.2.1.1.1.4 
Iterationsklausel B.4.5, ADA 25 


K 


kollektiv A.2.2.2 
Kommentar B.l 


368 


D. VERZEICHNISSE 


kompatibel B.1.2, B.2.1.4, B.2.1.5 
Komponente B.2, B.2.1.5 
-, typ B.2.1.2.1, ADA 20 
Konjunktion B.3.1, ADA 61 
Konkatenation B.3.6.1, B.3.6.3, ADA 61 
Konstante(n) B.1.2, B.2, B.2.1. 

-, Vereinbarung von B.2.2, ADA 18, ADA 20 
Kontextangabe B.10.4, ADA 2 
Kurzschlußformen B.3, B.3.1 

L 

Längenangabe B.8.2.1, ADA 50 

Leerzeichen B.l 

limitierter Typ ADA 20 

Linie, durchgezogen, gepunktet A.2.2.1 

logisch(e,er) 

- Ausdruck B.3.1, ADA 28 

- Konstante ADA 36 

lokale Größe B.10.4 
long_float B.2.1.1.2.4, ADA 22 
long_integer B.2.1.1.1.4, ADA 22 
low_level_io, Paket B.11.3 

n 

Marken B.2, B.4.6, ADA 23 
mehrschichtig A.2.2.2 
Mitgliedschaft B.3.1, ADA 
Model 1 

- intervall B.3.1 

- zahl B.2.1.1.2, B.3.1 

Modularität B.10 

modulo-Operator B.3.4, ADA 30, ADA 61 
Muttereinheit B.1.4 ADA 1, ADA 17 
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N 

Nachfolgeanweisung B.l 
Namen B.l, B.2, ADA 65 
Namenskonflikt B.10.5 
natural B.2.1.1.1.4, ADA 22 
Negation B.3.1, ADA 30 
new B.2.1.3, ADA 31 

o 

Operator (+ Unterprogramm) B.3, B.5, ADA 61 
- aufruf B.5.5, ADA 28, ADA 29, ADA 30 
Ordnung von Typen B.2.1.1 
others -Zweig B.4.8, ADA 24 


p 

Paket 

- erzeugung B.6.2, ADA 11 

- low_level_io B.11.3 

- Schema input__output B.ll.l 

- text_io B.11.2 

Parallelverarbeitung + Prozesse B.1.3 
Parameter B.2 
Pragma(-s) B.8.1 

- für Speicherplatzaufteilung B.8.1 

- - Festlegung der Objektmaschine B.8.1 

- - Speicherverwaltung B.8.1 

- - Aufruf von Unterprogrammen B.8.1 

- - Optimierung B.8.1 

- - Priorität von Prozessen B.8.1 

- - Programmtext B.8.1 

- - Unterdrücken von Tests B.8.1 
Pragmatik A.2, A.2.4 

Priorität eines Operators + Rangfolge 
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Priorität eines Prozesses B.9.6 
priority B.2.1.1.1.4, B.9 
Programm B.l, ADA 1 

- aufbau B.l, ADA 1 

- bibliothek B.10.1 

- Struktur B.10 

Prozedur (-*■ Unterprogramm) B.5 

- aufruf B.5.3, ADA 23 

Prozeß B.l, B.1.3, B.2, B.9, ADA 1, ADA 14, ADA 15 

- abhängigkeit B.9 
-, aktiver B.9.2 

- aktivierung B.9.1 

- handhabung B.9 
-, passiver B.9.2 

- rendezvous B.9.2 

- rendezvous, bedingtes B.9.3 

- rendezvous, verzögertes B.9.4 

- rümpf B.2.6, ADA 14 

- Spezifikation B.2.6, ADA 15 

- Synchronisierung B.9. 2.4 

- terminierung B.9.5 

- typ B.9 

- typvereinbarung B.2 

- Vereinbarung B.2.6, ADA 14, ADA 15 


R 

ränge B.2.1.1.1.4, B.2.1.2.1, ADA 33, ADA 47 
Rangfolge B.3 

raise -Anweisung B.7.3, ADA 23 
Record B.2.1.2.1 

- ausdruck B.3.7 

- darstellung B.8.2.3, ADA 51 

- konstante ADA 44 

- typ B.2.2.2, ADA 20, ADA 21 
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Rendezvous von Prozessen B.9.2, B.9.2.4 
-, bedingtes B.9.3 
-, verzögertes B.9.4 
reeller Typ B.2.1.1.2, ADA 22 
referierter Typ B.2.1.3, ADA 20 
Reihenfolge B.2 
renames -+ Umbennung 
Reservierter Name B.l, D.3 
Resultattyp B.l.l, ADA 7 
return -Anweisung B.4.7, B.5.2, ADA 23 
Rücksprung, Unterprogramm- B.5.2, ADA 23 
Rumpf, B.l, B.2, ADA 1, 6, 9, 14, 

- stumpf B.2, B.10.1, ADA 17 

- Unterprogramm- B.5, ADA 6 
Rundung B.2.1.1.2 

S 

Schablone (+ Schema) B.6 
Schema B.6 

- argument, aktuelles B.2.5, B.6.3, ADA 13 

- argumentliste, aktuelle B.6.3, ADA 12 

- argument, formales B.6.1, ADA 5 

- argumentliste, formale B.6.1, ADA 5 

- ausprägung B.6.2 

- Paketschema input_output B.ll.l 

- Vereinbarung B.2.5, B.6.1, ADA 3, ADA 4 
Schleife B.2, B.4.5 

Schleifenindex B.4.5 
Schreiben eines Programmes B.l 
Schrittweite ADA 20 
select -Anweisung B.9.3, ADA 24 
selectiv A.2.2.2 
Semantik A.2, A.2.3 
short float B.2.1.1.2.1, ADA 22 


24* 
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short_integer B.2.1.1.1.4, ADA 22 
Sichtbarkeit eines(r) B.10.3 

- Diskriminante 

- Eingangs 

- formalen Argumentes 

- getrennt übersetzten Paketes 

- getrennt übersetzten Unterprogrammes 

- Größe eines Programmes 

- Literais eines Aufzähltyps 

- Recordkomponente 

- Schleifenparameters (Laufvariable) 
skalarer Typ B.2.1.1 

slice B.2.2 

Speicherbelegungsfunktion B.3.8, ADA 31 
Speicherfreigabe, unkontrollierte B.8.3, ADA 8 
Spezifikation, Unterprogramm- B.5.1, ADA 7 
Sprunganweisung B.4.6, ADA 23 
Sprung aus der Schleife B.4.5, ADA 23 
Standardfunktionen 

- - Ein- bzw. Ausgabe B.ll, ADA 54 
Standardname B.2 
Standardprozeduren 

- - Ein- bzw. Ausgabe 

- - Fileverwaltung B.ll, ADA 53 
String 

- Ausdruck + Ausdruck für Zeichenketten 

- typ B.2.1.2.1.1, ADA 22 

- konstante ■+ Konstante ADA 42 
strukturierte Anweisung ADA 24 
Synchronisierung B.1.3, B.4.11, B.9.2.4 
Symbol A.2.1, A.2.2.1 

Syntax A.2, A.2.2 
Syntaxdiagramm A.2.2.1 
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T 

Teilfeld B.2.2 
terminate -AIternati ve B.9.5 
terminate-Anweisung B.9.5 

Terminierung eines Prozesses B.4.11, B.9.5, ADA 23 
abnormale B.9.5 
Textfi le( -s) (-* File) B. 11.2 

Spaltenposition eines B. 11.2.1 

- typ B.11.2.1 

- Verwaltung B.11.2.1 
Zeilenende eines B.11.2.1 
Zeilenlänge eines B.11.2.1 
Zeilenposition eines B.11.2.1 

text_io, Paket B.11.2 
Trennzeichen B.l 
x-Syntaxdiagramm A.2.2.2 
Typ(-en) B.2, ADA 22 

Array B.2.1.2.1, ADA 20, ADA 47 
-, Aufzählungs- B.2.1.1.1.1 
-, diskreter B.2.1.1.1 
-, Festpunkt- B.2.1.1.2.2, ADA 20, ADA 22 
-, File- B.11.1.1, ADA 22 
-, Gleitpunkt- B.2.1.1.2.1, ADA 20, ADA 22 

- konvertierung B.3.10, ADA 31 
-, reeller B.2.1.1.2, ADA 22 

-, Record B.2.1.2.7, ADA 20, ADA 21 
-, skalarer B.2.1, B.2.1.1 
-, String B.2.1.2.1.1, ADA 22 
-, strukturierter B.2.1, B.2.1.2 
-, Textfile- B.11.2.1 
-, Übersicht über die B.2.1 

- Umwandlung, unkontrol 1 ierte B.8.3, ADA 8 
-, Vereinbarung von B.2.1, ADA 18 

-, Zeiger- B.2.1, B.2.1.3 
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U 

überdecken von Namen B.10.5 
überladen 

- von Aufzählungsliteralen B.2.1.1.1.1 

- von Namen B.10.5 

- von Operatoren B.3.9 

- von Unterprogrammen B.5.7 
Übersetzungseinheiten B.l, B.10.1, ADA 1 
Übersetzung eines Programmes B.10.6 
Umbenennung B.28 ADA 18 

universal_integer -»- integer 
Unterbereich B.2.1.1 
Untereinheit B.l, B.1.4, B.10.1, ADA 1 
Unterprogramm(-en) 

(+ Funktion,-»- Operator,-»- Prozedur) B.1,B.2,B.5, ADA1,3,6,7 

- erzeugung B.6.2, ADA 8 

- rümpf B.5, ADA 6 

- rücksprung B.4.7, B.5.2, ADA 23 

- Schema B.l, B.2.5, B.6 

- Spezifikation B.l.l, B.5.1, ADA 7 

- überladen von B.5.7 

- Vereinbarung B.2.3, B.5.1, ADA 6, ADA 7 
Untertyp B.2.1.4, ADA 18, ADA 20 

use-KIausel B.2, B.10.4, ADA 2, ADA 18 

v 

Variable B.2 

-, Vereinbarung von B.2.2, ADA 18 
Variantenteil B.2.1.2.2, ADA 21 
Verarbeitung 

- eines Unterprogrammes B.l.l 

- eines Paketes B.2.1 

- eines Prozesses B.1.3 

- einer Bibliothekseinheit B.10.6 
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Verbreitung einer Ausnahme B.7.5 
Vereinbarung B.2, ADA 17 
- 9 Ausnahme - B.7.2, ADA 18 

-, Eingangs- B.2.1, ADA 16 
-, implizite B.2 

Schema- B.6.1, ADA 3, ADA 4 
Unterprogramm- B.5.1, ADA 6, ADA 7 
Vergleiches) B.3.1, ADA 29 

- operator B.3.1, ADA 61 
verträglich B.2.1 
Verweis Zeiger 

Verzweigung B.4.4, B.4.8, ADA 24 
Verzögerung(-s) 

- anweisung B.9.4, ADA 23 

- zeit B.9.4, ADA 24 
vordefinierte Ausnahme B.7.1, ADA 46 
Vorgänger eines Prozesses B.9 

vorzeitige (abnormale) Terminierung B.9.5, ADA 23 
verzögertes Rendezvous B.9.4 

w 

Wertebereich B.2.1.1, B.2.1.5 
Wertzuweisung B.4.2, ADA 23 
while -Klausel B.4.5, ADA 25 
Wiederholungsanweisung B.4.5, ADA 24 
with -Klausel B.10.4, ADA 2 
Wortsymbol A.2.2.1, B.l, D.2 

z 

Zunamen B.l, ADA 58 
Zeichen B.2.1.1.1.3 

- konstante ADA 37 
Zeichenkettenkonstante ADA 42 
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Zeiger Ausdruck B.3.8 

- Konstante ADA 46 

- Typ B.2.1.3 ADA 20, ADA 22 
Zeilenendezeichen B.l 
Zugriff Zeiger 

Zuname B.10.3, B.10.4, B.10.5, ADA 58 

- eines Eingangs B.9.2.2 

- einer Paketgröße B.10.4 
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197S. mit 50 Abb. 1973. (HTB31) 

Erwe, F. 

Gewöhnliche Differentialgleichungen 

152S. mit 11 Abb. 1964. (HTB19) 

Erwe, F. 

Reelle Analysis 

(Reihe: Mathematik für Physiker, Band 5) 
360 S. 1978. Wv. 

Erwe, F./E. Peschl 

Partielle Differentialgleichungen 

erster Ordnung 

133 S. 1973. (HTB87) 
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Ewald, G. 

Probleme der geometrischen 
Analysis 

160S. mit ca. 110 Figuren. 1982. Wv. 

Felscher, W. 

Naive Mengen und abstrakte Zahlen 
Band I: Die Anfänge der Mengenlehre und 
die natürlichen Zahlen. 

260 S. 1978. Wv. 

Band II: Die Struktur der algebraischen 
und der reellen Zahlen. 

222 S. 1978. Wv. 

Band III: Transfinite Methoden. 

272 S. 1979. Wv. 

Fuchssteiner, B./D. Laugwitz 
Funktionalanalysis 

(Reihe: Mathematik für Physiker, Band 9) 
219 S. 1974. Wv. 

Gericke, H. 

Geschichte des Zahlbegriffs 

163S. mit Abb. 1970. (HTB172) 

Goffmann, C. 

Reelle Funktionen 

331 S. Aus dem Englischen. 1976. Wv. 

Gröbner, W. 

Algebraische Geometrie 

Band I: Allgemeine Theorie der 
kommutativen Ringe und Körper. 

193S. 1968. (HTB273) 

Gröbner, W. 

Differentialgleichungen I. 
Gewöhnliche Differentialgleichungen 

(Reihe: Mathematik für Physiker, Band 6) 
188S. 1977. Wv. 

Gröbner, W. 

Differentialgleichungen II. 

Partielle Differentialgleichungen 

(Reihe: Mathematik für Physiker, Band 7) 
157 S. 1977. Wv. 

Gröbner, W./H. Knapp 
Contributions to the Method of Lie 
Series 

In englischer Sprache. 

265 S. 1967. (HTB802) 

Grotemeyer, K. P./E. Letzner/ 

R. Reinhardt 
Topologie 

187S. mit Abb. 1969. (HTB836) 


Gumm, H. P./W. Poguntke 
Boolesche Algebra 

95 S. 1981. (HTB604) 

Hämmerlin, G. 

Numerische Mathematik I 
Band I: Approximation, Interpolation, 
Numerische Quadratur, 
Gleichungssysteme. 

199S. 2., überarbeitete Aufl. 1978. 
(HTB498) 

Hasse, H./P. Roquette (Hrsg.) 
Algebraische Zahlentheorie 

272S. 1966. (M.F.0.2) 

Heidler, K./H. Hermes/ 

F.-K. Mahn 

Rekursive Funktionen 

248 S. 1977. Wv. 

Heil, E. 

Differentialformen 

207 S. 1974. Wv. 

Hein, O. 

Graphentheorie für Anwender 

141 S. 1977. (HTB83) 

Hein, O. 

Statistische Verfahren der 
Ingenieurpraxis 

197S. Mit 5 Tabellen, 6 Diagrammen, 43 
Beispielen. 1978. (HTB119) 

Hellwig, G. 

Höhere Mathematik 
Band 1/1. Teil: Zahlen, Funktionen, 
Differential- und Integralrechnung einer 
unabhängigen Variablen. 

284, IXS. 1971. (HTB553) 

Band 1/2. Teil: Theorie der Konvergenz 
Ergänzungen zur Integralrechnung, das 
Stieltjes-Integral. 137S. 1972. (HTB560) 

Hengst, M. 

Einführung in die mathematische 
Statistik und ihre Anwendung 

259 S. mit Abb. 1967. (HTB42) 

Henze, E. 

Einführungen in die Maßtheorie 

235 S. 1971. (HTB505) 

Heyer, H. 

Einführung in die Theorie 
Markoffscher Prozesse 

253 S. 1979. Wv. 
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Hirzebruch, F./W. Scharlau 
Einführung in die Funktionalanalysis 

178 S. 1971. (HTB296) 

Hlawka, E. 

Theorie der Gleichverteilung 

152S. 1979. Wv. 

Holmann, H./H. Rummler 
Alternierende Differentialformen 

257 S. 2., durchgesehene Aufl. 1981. Wv. 

Horvath, H. 

Rechenmethoden und ihre 
Anwendung in Physik und Chemie 

142S. 1977. (HTB78) 

Hoschek, J. 

Liniengeometrie 

VI, 263S. mit Abb. 1971. (HTB733) 

Hoschek, J./G. Spreitzer 
Aufgaben zur darstellenden 
Geometrie 

229 S. mit Abb. 1974. Wv. 

Ince, E. L. 

Die Integration gewöhnlicher 
Differentialgleichungen 

180 S. Aus dem Englischen. 1965. (HTB67) 

Joachim, E. 

Einführung in die Algebra 

168S. 2. Aufl. 1980. (HTB138) 

Jordan-Engeln, G./F. Reutter 
Formelsammlung zur Numerischen 
Mathematik mit Standard 
Fortran-Programmen 

424 S. 3., überarb. und erweiterte Aufl. 1981. 
(HTB106) 

Jordan-Engeln, G./F. Reutter 
Numerische Mathematik für 
Ingenieure 

Etwa 400 S. 3., überarbeitete und erw. Aufl. 
1982. (HTB104) 

Kaiser, R./G. Gottschalk 
Elementare Tests zur Beurteilung von 
Meßdaten 

68 S. 1972. (HTB774) 

Kießwetter, K. 

Reelle Analysis einer Veränderlichen. 
Ein Lern- und Übungsbuch 

316 S. 1975. (HTB269) 


Kießwetter, K./R. Rosenkranz 
Lösungshilfen für Aufgaben zur 
reellen Analysis einer Veränderlichen 

231 S. 1976. (HTB270) 

Klingbeil, E. 

Tensorrechnung für Ingenieure 

197 S. mit Abb. 1966. (HTB197) 

Klingbeil, E. 

Variationsrechnung 

332 S. 1977. Wv. 

Klingenberg, W. (Hrsg.) 
Differentialgeometrie im Großen 

351 S. 1971. (M.F.0.4) 

Klingenberg, W./P. Klein 
Lineare Algebra und analytische 
Geometrie 

Band I: Grundbegriffe, Vektorräume. XII, 
288 S. 1971. (HTB748) 

Band II: Determinanten, Matrizen, 
Euklidische und unitäre Vektorräume. XVIII, 
404 S. 1972. (HTB 749) 

Klingenberg, W./P. Klein 
Lineare Algebra und analytische 
Geometrie. Übungen zu Band l-ll 

VIII, 172S. 1973. (HTB 750) 

Laugwitz, D. 

Infinitesimalkalkül. Kontinuum und 
Zahlen. Eine elementare Einführung 
in die Nichtstandard-Analysis 

187 S. 1978. Wv. 

Laugwitz, D. 

Ingenieurmathematik 

Band I: Zahlen, analytische Geometrie, 

Funktionen. 

158S. mit 43 Abb. 1964. (HTB 59) 

Band II: Differential- und Integralrechnung. 
152S. mit 43 Abb. 1964. (HTB 60) 

Band III: Gewöhnliche 
Differentialgleichungen. 

141 S. 1964. (HTB 61) 

Band IV: Fourier-Reihen, verallgemeinerte 
Funktionen, mehrfache Integrale, 
Vektoranalysis, Differentialgeometrie, 
Matrizen, Elemente der Funktionalanalysis. 
196S. mit Abb. 1967. (HTB 62) 

Band V: Komplexe Veränderliche. 

158 S. mit Abb. 1965. (HTB 93) 
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Laugwitz, D./C. Schmieden 
Aufgaben zur Ingenieurmathematik 

182S. 1966. (HTB95) 

Lebedew, N. N. 

Spezielle Funktionen und ihre 
Anwendung 

372S. mit Abb. Aus dem Russischen. 1973. 
Wv. 

Lidl, R./G. Pilz 

Angewandte abstrakte Algebra 
Band I: 249 S. 1982. Wv. 

Band II: Etwa 240 S. 1982. Wv. 

Lighthill, M. J. 

Einführung in die Theorie der 
Fourieranalysis und der 
verallgemeinerten Funktionen 

96 S. mit Abb. Aus dem Englischen. 1966. 
(HTB139) 

Lingenberg, R. 

Grundlagen der Geometrie 

224 S. mit 73 Abb. 3., durchgesehene Aufl. 
1978. Wv. 

Lingenberg, R. 

Lineare Algebra 

161 S. 1969. (HTB828) 

Lorenz, F. 

Lineare Algebra 

Band I: 233S. 1982. (HTB601) 

Band II: Etwa 200S. 1982. (HTB 605) 

Lorenzen, P. 

Metamathematik 

175 S. 2. Aufl. 1980. Wv. 

Lüneburg, H. 

Galoisfelder, Kreisteilungskörper und 
Schieberegisterfolgen 

143S. 1979. Wv. 

Lüneburg, H. 

Vorlesungen Uber Analysis 

467 S. 1981. Wv. 

Lutz, D. 

Topologische Gruppen 

175S. 1976. Wv. 

Mainzer, K. 

Geschichte der Geometrie 

232 S. 1980. Wv. 


Marsal, D. 

Die numerische Lösung partieller 
Differentialgleichungen in 
Wissenschaft und Technik 

XXVIII, 574S. mit Abb. 1976. Wv. 

Martensen, E. 

Analysis. 

Für Mathematiker, Physiker, 
Ingenieure 

Band I: Grundlagen der 
Infinitesimalrechnung. 

IX, 200 S. 2. Aufl. 1976. (HTB 832) 

Band II: Aufbau der Infinitesimalrechnung. 

VIII, 176S. 2., neu bearbeitete Aufl. 1978. 
(HTB 833) 

Band III: Gewöhnliche 
Differentialgleichungen. 

IX, 237 S. mit 52 Abb. 2., neu bearbeitete 
Aufl. 1980. (HTB 834) 

Meinardus, G. 

Approximation in Theorie und Praxis. 
Ein Symposiumbericht 

304 S. 1979. Wv. 

Meinardus, G./G. Merz 
Praktische Mathematik I. 

Für Ingenieure, Mathematiker und 
Physiker 

Band I: 346 S. 1979. Wv. 

Band II: 427 S. 1982. Wv. 

Meschkowski, H. 

Einführung in die moderne 
Mathematik 

214S. mit 44 Abb. 3., verbesserte Aufl. 
1971. (HTB 75) 

Meschkowski, H. 

Elementare 

Wahrscheinlichkeitsrechnung und 
Statistik 

(Reihe: Mathematik für Physiker, Band 3) 
188S. 1972. Wv. 

Meschkowski, H. 

Funktionen 

(Reihe: Mathematik für Physiker, Band 2) 
179S. mit 66 Abb. 1970. Wv. 

Meschkowski, H. 

Grundlagen der Euklidischen 
Geometrie 

231 S. mit 145 Abb. 2., verbesserte Aufl. 
1974. Wv. 
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Meschkowski, H. 

Mathematik und Realität. Vorträge 
und Aufsätze. 

184S. 1979. Wv. 

Meschkowski, H. 
Mathematiker-Lexikon 

342S. 3., überarbeitete und ergänzte Aufl. 
1980. Wv. 

Meschkowski, H. 

Mathematisches Begriffswörterbuch 

315S. mit Abb. 4.Aufl. 1976. (HTB99) 

Meschkowski, H. 
Mehrsprachenwörterbuch 
mathematischer Begriffe 

135S. 1972. Wv. 

Meschkowski, H. 

Problemgeschichte der Mathematik I 

206 S. 1979. Wv. 

Meschkowski, H. 

Problemgeschichte der Mathematik II 

235 S. 1981. Wv. 

Meschkowski, H. 

Problemgeschichte der neueren 
Mathematik (1800-1950) 

314S. mit Abb. 1978. Wv. 

Meschkowski, H. 

Richtigkeit und Wahrheit in der 
Mathematik 

219 S. 2., durchgesehene Aufl. 1978. Wv. 

Meschkowski, H. 

Unendliche Reihen 

320S. 2., verb. und erweiterte Aufl. 1982. 
Wv. 

Meschkowski, H. 

Ungelöste und unlösbare Probleme 
der Geometrie 

204 S. 2., verb. und erweiterte Aufl. 1975. 
Wv. 

Meschkowski, H. 
Wahrscheinlichkeitsrechnung 

233 S. mit Abb. 1968. (HTB285) 

Meschkowski, H. 

Zahlen 

(Reihe: Mathematik für Physiker, Band 1) 
174S. mit 37Abb. 1970. Wv. 


Meschkowski, H./I. Ahrens 
Theorie der Punktmengen 

183S. mit Abb. 1974. Wv. 

Niven, l./H. S. Zuckermann 
Einführung in die Zahlentheorie 
Band I: Teilbarkeit, Kongruenzen, 
quadratische Reziprozität u.a. 

213 S. Aus dem Englischen. 1976. (HTB46) 
Band II: Kettenbrüche, algebraische 
Zahlen, die Partitionsfunktion u.a. 

186S. Aus dem Englischen. 1976. (HTB47) 

Noble, B. 

Numerisches Rechnen 

Band II: Differenzen, Integration und 

Differentialgleichungen. 

246 S. Aus dem Englischen. 1973. (HTB147) 

Oberschelp, A. 

Elementare Logik und Mengenlehre 
Band I: Die formalen Sprachen, Logik. 
254S. 1974. (HTB 407) 

Band II: Klassen, Relationen, Funktionen, 
Anfänge der Mengenlehre. 

229S. 1978. (HTB 408) 

Peschl, E. 

Differentialgeometrie 

92 S. 1973. (HTB 80) 

Peschl, E. 

Funktionentheorie 

Band I: 274S. mit Abb. 1967. (HTB 131) 

Poguntke, W./R. Wille 
Testfragen zur Analysis I 

117S. 2.Aufl. 1980. (HTB781) 

Preuß, G. 

Grundbegriffe der Kategorientheorie 

105 S. 1975. (HTB 739) 

Reiften, H.-J./H. W. Trapp 
Einführung in die Analysis 
Band II: Theorie der analytischen und 
differenzierbaren Funktionen. 

260 S. 1973. (HTB 786) 

Rommelfanger, H. 

Differenzen- und 
Differentialgleichungen 

232 S. 1977. Wv. 
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Rothstein, W./K. Kopfermann 
Funktionentheorie mehrerer 
komplexer Veränderlicher 

256 S. 1982. Wv. 

Rottmann, K. 

Mathematische Formelsammlung 

176 S. mit 39 Abb. 1962. (HTB13) 

Rottmann, K. 

Siebenstellige dekadische 
Logarithmen 

194S. 1960. (HTB17) 

Rutsch, M. 

Wahrscheinlichkeit I 

350 S. mit Abb. 1974. Wv. 

Rutsch, M./K.-H. Schriever 
Wahrscheinlichkeit II 

404 S. mit Abb. 1976. Wv. 

Rutsch, M./K.-H. Schriever 
Aufgaben zur Wahrscheinlichkeit 

267 S. mit Abb. 1974. Wv. 

Schick, K. 

Lineare Optimierung 

331 S. mit Abb. 1976. (HTB64) 

Schmidt, J. 

Mengenlehre. Einführung in die 
axiomatische Mengenlehre 
Band I: 245 S. mit Abb. 2., verb. und 
erweiterte Aufl. 1974. (HTB56) 

Schwabhäuser, W. 

Modelltheorie 

Band II: 123S. 1972. (HTB815) 

Schwartz, L. 

Mathematische Methoden der Physik 
Band I: Summierbare Reihen, 
Lebesque-Integral, Distributionen, Faltung. 
Aus dem Französischen. 

184S. 1974. Wv. 

Schwarz, W. 

Einführung in die Siebmethoden der 
analytischen Zahlentheorie 

215 S. 1974. Wv. 

Spallek, K. 

Kurven und Karten 

272 S. 1980. Wv. 


Tamaschke, O. 
Permutationsstrukturen 

276S. 1969. (HTB710) 

Tamaschke, O. 

Schur-Ringe 

240S. mit Abb. 1970. (HTB735) 

Teichmann, H. 

Physikalische Anwendungen der 
Vektor- und Tensorrechnung 

231 S. mit 64 Abb. 3. Aufl. 1975. (HTB39) 

Uhde, K. 

Spezielle Funktionen der 
mathematischen Physik 
Band I: Tafeln, Zylinderfunktionen. 

267S. 1964. (HTB55) 

Voigt, A./J. Wloka 
Hilberträume und elliptische 
Differentialoperatoren 

260 S. 1975. Wv. 

Waerden, B. L. van der 
Mathematik für Naturwissenschaftler 

280S. mit 167 Abb. 1975. (HTB281) 

Wagner, K. 

Graphentheorie 

220S. mit Abb. 1970. (HTB248) 

Walter, R. 

Differentialgeometrie 

286 S. 1978. Wv. 

Walter, W. 

Einführung in die Theorie der 
Distributionen 

VIII, 21 IS. mit Abb. 1974. Wv. 

Weizel, R./J. Weyland 
Gewöhnliche Differentialgleichungen. 
Formelsammlung mit 
Lösungsmethoden und Lösungen 

194S. mit Abb. 1974. Wv. 

Werner, H. 

Einführung in die allgemeine Algebra 

152S. 1978. (HTB120) 
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Werner, H. und l./P. Janßen/ 

H. Arndt 

Probleme der praktischen 
Mathematik. 

Eine Einführung 
Band I: mathematische Hilfsmittel, 
Fehlertheorie, Lösung von 
Gleichungssystemen u.a. 

159S. 2. Aufl. 1980. (HTB134) 

Band il: Interpolation, Approximation, 
numerische Differentiation und Integration, 
gewöhnliche Differentialgleichungen u.a. 
169S. 2. Aufl. 1980. (HTB135) 

Wollny, W. 

Reguläre Parkettierung der 
euklidischen Ebene durch 
unbeschränkte Bereiche 

316S. mit Abb. 1970. (HTB711) 

Wunderlich, W. 

Darstellende Geometrie 

Band I: 187S. mit Abb. 1966. (HTB96) 

Band II: 234S. mit Abb. 1967. (HTB133) 


Reihe: Jahrbuch Überblicke 
Mathematik 


Herausgegeben von Prof. Dr. S. D. 
Chatterji, Eidgen. Techn. Hochschule 
Lausanne, Prof. Dr. Istvan Fenyö, Techn. 
Universität Budapest, Prof. Dr. Benno 
Fuchssteiner, Gesamthochschule 
Paderborn, Prof. Dr. Ulrich Kulisch, 
Universität Karlsruhe, Prof. Dr. Detlef 
Laugwitz, Techn. Hochschule Darmstadt, 
Prof. Dr. Roman Liedl, Universität 
Innsbruck. 

Die Jahrbücher 1975, 1977 und 1979 sind 
vergriffen. 

Jahrbuch Überblicke Mathematik 

197 6. 204S. mit Abb. 1976. Wv. 

Jahrbuch Überblicke Mathematik 

19 78. 224S. 1978. Wv. 

Jahrbuch Überblicke Mathematik 
1980. 214S. 1980. Wv. 


Jahrbuch Überblicke Mathematik 
1982. 218 S. 1982. Wv. 


Reihe: Überblicke 
Mathematik 


Herausgegeben von Prof. Dr. Detlef 
Laugwitz, Techn. Hochschule Darmstadt. 

Band 1: 213S. 1968. (HTB161) 

Band 2: 210S. 1969. (HTB232) 

Band 3: 157S. 1970. (HTB247) 

Band 4: 123S. 1972. Wv. 

Band 5: 186S. 1972. Wv. 

Band 6: 242 S. mit Abb. 1973. Wv. 

Band 7: 265, IIS. mit Abb. 1974. Wv. 


Reihe: Methoden und Verfahren 
der mathematischen Physik 


Herausgegeben von Prof. Dr. Bruno 
Brosowski, Universität Frankfurt und Prof. 
Dr. Erich Martensen, Universität Karlsruhe. 

Band 1s 183S. 1969. (HTB720) 

Band 2: 179S. 1970. (HTB721) 

Band 3: 176S. 1970. (HTB722) 

Band 4: 177S. 1971. (HTB723) 

Band 5: 199S. 1971. (HTB724) 

Band 6: 163S. 1972. (HTB725) 

Band 7: 176S. 1972. (HTB726) 

Band 8: 222 S. mit Abb. 1973. Wv. 

Band 9: 201 S. mit Abb. 1973. Wv. 

Band 10: 184S. 1973. Wv. 

Band 11 : 190S. mit Abb. 1974. Wv. 

Band 12: 214S. mit Abb. 1975. 
Mathematical Geodesy, Part. 1. Wv. 
ßand 13: 206S. mit Abb. 1975. 
Mathematical Geodesy, Part. 2. Wv. 

Band 14: 176S. mit Abb. 1975. 
Mathematical Geodesy, Part. 3. Wv. 

Band 15: 166S. 1976. Wv. 

Band 16: 180S. 1976. Wv. 


Jahrbuch Überblicke Mathematik 
1981. 264 S. 1981. Wv. 
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Informatik 


Alefeld, G./J. Herzberg er/ 

O. Mayer 

Einführung in das Programmieren mit 
ALGOL 60 

164S. 1972. (HTB777) 

Bosse, W. 

Einführung in das Programmieren mit 
ALGOL W 

249 S. 1976. (HTB 784) 

Breuer, H. 

Algol-Fibel 

120 S. mit Abb. 1973. (HTB 506) 

Breuer, H. 

Fortran-Fibel 

85S. mit Abb. 1969. (HTB 204) 

Breuer, H. 

PL/1-Fibel 

106S. 1973. (HTB 552) 

Bruderer, H. E. 

Nichtnumerische Datenverarbeitung 

267 S. mit 60 Abb. 2.Aufl. 1980. Wv. 

Dederichs, W. 

APPLESOFT-BASIC 

188S. 1982. (HTB 603) 

Dotzauer, E. 

Einführung in APL 

248 S. 1978. (HTB 753) 

Haase, V./W. Stucky 
BASIC 

Programmieren für Anfänger 

230S. 1977. (HTB 744) 

Händler, W./G. Nees (Hrsg.) 
Rechnergestützte Aktivitäten CAD 

176S. 1980. Wv. 

Hainer, K. 

Numerische Algorithmen auf 
programmierbaren Taschenrechnern 

263 S. 1980. (HTB 805) 


Kaucher, E./R. Klatte/Ch. Ullrich 
Programmiersprachen im Griff 
Band 1: FORTRAN 
310S. 1980. (HTB795) 

Band 2: PASCAL 
359S. 1981. (HTB 796) 

Band 3: BASIC 
390S. 1981. (HTB 797) 

Lawson jr., H. W./E. J. Neuhold 
Verstehen Sie Datenverarbeitung? 

Etwa 250 S. 1982. Wv. 

Mell, W.-D./P. Preuß/P. Sandner 
Einführung in die 
Programmiersprache PL/1 

304S. 1974. (HTB 785) 

Mickel, K.-P. 

Einführung in die 
Programmiersprache COBOL 

219S. 2., verbesserte Aufl. 1980. (HTB 745) 

Müller, K. H./I. Streker 
FORTRAN. 

Programmierungsanleitung 

215 S. 2. Aufl. 1970. (HTB 804) 

Rohlfing, H. 

PASCAL. Eine Einführung 

217S. 1978. (HTB756) 

Rohlfing, H. 

SIMULA 

243 S. mit Abb. 1973. (HTB 747) 

Schließmann, H. 

Programmierung mit PL/1 

206 S. 2., erweiterte Aufl. 1978. (HTB 740) 

Weber, H./J. Grami 
Numerische Verfahren für 
programmierbare Taschenrechner I 

192S. 1980. (HTB 803) 

Zimmermann, G./J. Höffner 
Elektrotechnische Grundlagen der 
Informatik II 

Wechselstromlehre, Leitungen, analoge u. 
digitale Verarbeitung kontinuierlicher 
Signale. 

194S. mit Abb. 1974. (HTB 790) 
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... 

Reihe: Informatik 



Herausgegeben von Prof. Dr. Karl Heinz 
Böhling, Universität Bonn, Prof. Dr. Ulrich 
Kulisch, Universität Karlsruhe und Prof. Dr. 
Hermann Maurer, Technische Universität 
Graz. 

Band 1: 

Maurer, H. 

Theoretische Grundlagen der 
Programmiersprachen. 

Theorie der Syntax 

254 S. Unveränderter Neudruck 1977. Wv. 

Band 2: 

Heinhold, J./U. Kulisch 
Analogrechnen 

242 S. mit Abb. 1976. Wv. 

Band 7: 

Kameda, T./K. Weihrauch 
Einführung in die Codierungstheorie 
Teil I: 218S. 1973. Wv. 

Band 8: 

Reusch, B. 

Lineare Automaten 

149S. mit Abb. 1969. (HTB708) 

Band 10: 

Böhling, K. H./G. Dittrich 
Endliche stochastische Automaten 

138S. 1972. (HTB766) 

Band 11: 

Seegmüller, G. 

Einführung in die 
Systemprogrammierung 

480 S. mit 83 Abb. 1974. Wv. 

Band 12: 

Alefeld, G./J. Herzberger 
Einführung in die Intervallrechnung 

XIII, 398 S. mit Abb. 1974. Wv. 

Band 13: 

Duske, J./H. JUrgensen 
Codierungstheorie 

235 S. 1977. Wv. 

Band 14: 

Böhling, K. H./B. v. Braunmühl 
Komplexität bei Turingmaschinen 

324 S. 1974. Wv. 


Band 15: 

Peters, F. E. 

Einführung in mathematische 
Methoden der Informatik 

348 S. 1974. Wv. 

Band 16: 

Wedekind, H. 

Datenbanksysteme I 

325S. 2., völlig neu bearb. Aufl. 1981. Wv. 

Band 18: 

Wedekind, H./T. Härder 
Datenbanksysteme II 

430 S. mit Abb. 1976. Wv. 

Band 19: 

Kulisch, U. 

Grundlagen des numerischen 
Rechnens. Mathematische 
Begründung der Rechnerarithmetik 

467 S. 1976. Wv. 

Band 20: 

Zima, H. 

Betriebssysteme. 

Parallele Prozesse 

325S. 2. Aufl. 1980. Wv. 

Band 21: 

Mies, P./D. Schütt 
Feldrechner 

150S. 1976. Wv. 

Band 22: 

Denert, E./R. Franck 
Datenstrukturen 

362 S. 1977. Wv. 

Band 23: 

Ecker, K. 

Organisation von parallelen 
Prozessen. Theorie deterministischer 
Schedules 

280 S. 1977. Wv. 

Band 24: 

Kaucher, E./R. Klatte/Ch. Ullrich 
Höhere Programmiersprachen 
ALGOL, FORTRAN, PASCAL in 
einheitlicher und übersichtlicher 
Darstellung 
258 S. 1978. Wv. 
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Band 25: 

Mötsch, W. 

Halbleiterspeicher. 

Technik, Organisation und 

Anwendung 

237 S. 1978. Wv. 

Band 26: 

Görke, W. 

Mikrorechner. 

Eine Einführung in ihre Technik und 
Funktion 

251 S. 2., überarbeitete und erweiterte Aufl. 
1980. Wv. 

Band 27: 

Mayer, O. 

Syntaxanalyse 

433 S. 2., durchgesehene und ergänzte Aufl. 
1982. Wv. 

Band 28: 

Schrack, G. 

Grafische Datenverarbeitung. 

Eine Einführung 

264 S. 1978. Wv. 

Band 29: 

Waller, H./P. Hilgers 
Mikroprozessoren. 

Vom Bauteil zur Anwendung 

332S. mit Abb. 1980. Wv. 

Band 30: 

Reusch, P. 

Informationssysteme, 
Dokumentationssprachen, Data 
Dictionaries. Eine Einführung 

216 S. 1980. Wv. 

Band 31: 

Ershov, A. P. 

Einführung in die Theoretische 
Programmierung. 

Gespräche über die Methode 

Etwa 450 S. mit Abb. Aus dem Russischen. 
1982. Wv. 

Band 32: 

Koch, G. 

Maschinennahes Programmieren von 
Mikrocomputern 

274 S. 1981. Wv. 


Band 33: 

Stetter, F. 

Softwaretechnologie. 

Eine Einführung 

303 S. 1981. Wv. 

Band 34: 

Balzert, H. 

Die Entwicklung von 
Software-Systemen. 

Prinzipien, Methoden, Sprachen, 

Werkzeuge 

Etwa 300 S. 1982. Wv. 

Band 35: 

Hotz, G./K. Estenfeld 
Formale Sprachen. 

Eine automatentheoretische 
Einführung 

234 S. 1981. Wv. 

Band 36: 

Zima, H. 

Compilerbau I. 

Analyse 

Etwa 350 S. 1982. Wv. 


Physik 


Baltes, H. P./E. R. Hilf 
Spectra of Finite Systems 

116S. In englischer Sprache. 1976. Wv. 

Barut, A. O. 

Die Theorie der Streumatrix für die 
Wechselwirkungen fundamentaler 
Teilchen 

Band I: Gruppentheoretische 
Beschreibung der S-Matrix. 

225 S. mit Abb. Aus dem Englischen. 1971. 
(HTB438) 

Band II: Grundlegende Teilchenprozesse. 
212S. mit Abb. Aus dem Englischen. 1971. 
(HTB555) 

Bethge, K. 

Quantenphysik. 

Eine Einführung in die Atom- und 
Molekülphysik 

271 S. 1978. Wv. Unter Mitarbeit von Dr. G. 
Gruber, Universität Frankfurt. 
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Bjorken, J. D./S. D. Drell 
Relativistische Quantenmechanik 

312S. mit Abb. 1966. Aus dem Englischen. 
(HTB98) 

Bjorken, J. D./S. D. Drell 
Relativistische Quantenfeldtheorie 

409 S. Unveränderter Neudruck 1978. Aus 
dem Englischen. (HTB101) 

Bleuler, K./H. R. Petry/ 

D. Schütte (Hrsg.) 

Mesonic Effects in Nuclear Structure 

181 S. mit Abb. In englicher Sprache. 1975. 
Wv. 

Blum, P./K. Schuchardt/V. Gärtner 
Die Hochatmosphäre. 

Eine Einführung 

Etwa 250 S. mit zahlr. Abb. 1982. Wv. 

Bodenstedt, E. 

Experimente der Kernphysik und ihre 
Deutung 

Band l:290S. mit Abb. 2., durchgesehene 
Aufl. 1979. Wv. 

Band II: XIV, 293S. mit Abb. 2., 
durchgesehene Aufl. 1978. Wv. 

Band III: 303S. mit Abb. 2., 
durchgesehene Aufl. 1979. Wv. 

Borucki, H. 

Einführung in die Akustik 

236 S. 2., durchgesehene Aufl. 1980. Wv. 

Donner, W. 

Einführung in die Theorie der 
Kernspektren 

Band II: Erweiterung des Schalenmodells, 
Riesenresonanzen. 

107S. mit Abb. 1971. (HTB556) 

Eder, G. 

Quantenmechanik I 

273 S. 2. Aufl. 1980. Wv. 

Eder, G. 

Atomphysik. 

Quantenmechanik II 

259 S. 1978. Wv. 

Eder, G. 

Elektrodynamik 

273 S. 1967. (HTB233) 


Emendörfer, D./K. H. Höcker 
Theorie der Kernreaktoren 
Band 1: Der stationäre Reaktor. 

Etwa 380S. mit Abb. 2., neu bearbeitete 
Aufl. 1982. Wv. 

Gasiorowicz, S. 
Elementarteilchenphysik 

742S. mit 119Abb. 1975. Aus dem 
Englischen. Wv. 

Grott, S. R. de 

Thermodynamik irreversibler 
Prozesse 

216S. mit 4 Abb. 1960. Aus dem Englischen. 
(HTB18) 

Groot, S. R. de/P. Mazur 
Anwendung der Thermodynamik 
irreversibler Prozesse 

349 S. 1974. Aus dem Englischen. Wv. 

Haken, H. 

Licht und Materie I. 

Elemente der Quantenoptik 

155S. 1979. Wv. 

Haken, H. 

Licht und Materie II. 

225 S.*" 1981. Wv. 

Heisenberg, W. 

Physikalische Prinzipien der 
Quantentheorie 

117 S. mit 22 Abb. 1958. (HTB 1) 

Henley, E. M./W. Thirring 
Elementare Quantenfeldtheorie 

336S. mit Abb. 1975. Aus dem Englischen. 
Wv. 

Hund, F. 

Geschichte der physikalischen 
Begriffe 

Teil I: Die Entstehung des mechanischen 
Naturbildes. 

221 S. 2., neu bearbeitete Aufl. 1978. 

(HTB 543) 

Teil II: Die Wege zum heutigen Naturbild. 
233S. 2., neu bearbeitete Aufl. 1978. 

(HTB 544) 

Hund, F. 

Geschichte der Quantentheorie 

262 S. mit Abb. 2. Aufl. 1975. Wv. 
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Hund, F. 

Grundbegriffe der Physik 
Teil I: Makroskopische Vorgänge. 

150S. mit Abb. 2., neu bearbeitete Aufl. 
1979. (HTB449) 

Teil II: Mikroskopischer Hintergrund. 

151 S. mit Abb. 2., neu bearbeitete Aufl. 
1979. (HTB450) 

Källen, G./J. Steinberger 
Elementarteilchenphysik 

687S. mit Abb. 2., verbesserte Aufl. 1974. 
Aus dem Englischen. Wv. 

Kippenhahn, R./C. Möllenhoff 
Elementare Plasmaphysik 

297 S. mit Abb. 1975. Wv. 

Luchner, K. 

Aufgaben und Lösungen zur 

Experimentalphysik 

Band II: Elektromagnetische Vorgänge. 

150S. mit Abb. 1966. (HTB156) 

Band III: Grundlagen zur Atomphysik. 
125S. mit Abb. 1973. (HTB 157) 

Lüscher, E. 

Experimentalphysik 

Band I: Mechanik, geometrische Optik, 

Wärme. 

Band 1/1. Teil: 260S. mit Abb. 1967. 
(HTB 111) 

Band 1/2. Teil: 215S. mit Abb. 1967. 
(HTB 114) 

Band II: Elektromagnetische Vorgänge. 
371 S. 2., überarb. Aufl. 1981. (HTB 115) 

Lüst, R. 

Hydrodynamik 

234 S. 1978. Wv. 

Mitter, H. 

Elektrodynamik 

391 S. 1980. (HTB 707) 

Mitter, H. 

Quantentheorie 

313S. mit Abb. 2. Aufl. 1979. (HTB701) 

Meller, C. 

Relativitätstheorie 

316 S. 1977. Wv. 

Neff, H. 

Physikalische Meßtechnik 

160S. mit Abb. 1976. (HTB 66) 


Neuert, H. 

Experimantalphysik für Mediziner, 
Zahnmediziner, Pharmazeuten und 
Biologen 

292 S. mit Abb. 1969. (HTB 712) 

Neuert, H. 

Physik für Naturwissenschaftler 
Band I: Mechanik und Wärmelehre. 

173 S. 1977. (HTB 727) 

Band II: Elektrizität und Magnetismus, 
Optik. 198S. 1977. (HTB728) 

Band III: Atomphysik, Kernphysik, 
chemische Analyseverfahren. 

326 S. 1978. (HTB 729) 

Nitsch, J./J. Pfarr/ 

E.-W. Stachow (Hrsg.) 
Grundlagenprobleme der modernen 
Physik 

319 S. 1981. Wv. 

Rollnik, H. 

Teilchenphysik 

Band I: Grundlegende Eigenschaften von 
Elementarteilchen. 

Etwa 188S. 2. Aufl. 1982. (HTB 706) 

Band II: Innere Symmetrien der 
Elementarteilchen. 

158S. mit Abb. z.T. farbig. 1971. (HTB 759) 

Rose, M. E. 

Relativistische Elektronentheorie 
Band I: 193S. mit Abb. 1971. Aus dem 
Englischen. (HTB 422) 

Band II: 171S. mit Abb. 1971. Aus dem 
Englischen. (HTB 554) 

Scherrer, P./P. Stoll 
Physikalische Übungsaufgaben 
Band I: Mechanik und Akustik. 

96 S. mit 44 Abb. 1962. (HTB 32) 

Band II: Optik, Thermodynamik, 
Elektrostatik. 

103 S. mit Abb. 1963. (HTB 33) 

Band III: Elektrizitätslehre, Atomphysik. 
103S. mit Abb. 1964. (HTB 34) 

Schütte, D./K. Holinde/ 

K. Bleuler (Hrsg.) 

The Meson Theory of Nuclear Forces 
and Nuclear Matter 

393 S. 1980. Wv. 


14 


Seiler, H. 

Abbildungen von Oberflächen mit 
Elektronen, Ionen und 
Röntgenstrahlen 

131 S. mit Abb. 1968. (HTB428) 

Sexl, R. U./H. K. Urbantke 
Gravitation und Kosmologie. 

Eine Einführung in die Allgemeine 
Relativitätstheorie 

Etwa 370S. 2., überarb. und erweiterte Aufl. 
1982. Wv. 

Teichmann, H. 

Einführung in die Atomphysik 

135 S. mit 47 Abb. 3. Auflage 1966. (HTB12) 

Teichmann, H. 

Halbleiter 

156 S. mit 55 Abb. 3. Auflage 1969. (HTB 21) 

Wagner, C. 

Methoden der 

naturwissenschaftlichen und 
technischen Forschung 

219S. mit Abb. 1974. Wv. 



Becker, F. 

Geschichte der Astronomie 

201 S. 4. Aufl. 1980. Wv. 


Scheffler, H./H. Elsässer 
Bau und Physik der Galaxis 

Etwa 650 S. 1982. Wv. 

Scheffler, H./H. Elsässer 
Physik der Sterne und der Sonne 

535 S. mit Abb. 1974. Wv. 

Schneider, M. 

Himmelsmechanik 

480 S. mit Abb. 2., verbesserte Aufl. 1981. 
Wv. 

Schurig, R./P. Götz/K. Schaifers 
Himmelsatlas (Tabuale caelestes) 

44 S. 8. Aufl. 1960. Wv. 


Weizel, W. 

Einführung in die Physik 
Band III: Optik und Atomphysik. 

194S. mit 99 Abb. 5. Auflage 1963. (HTB 5) 


Voigt, H. H. 

Abriß der Astronomie 

558 S. mit Abb. 3., überarbeitete Aufl. 1980. 
Wv. 


Weizel, W. 

Physikalische Formelsammlung 
Band II: Optik, Thermodynamik, 
Relativitätstheorie. 

148S. 1964. (HTB 36) 

Band III: Quantentheorie. 

196 S. mit zweifarbigem Druck der Formeln. 
1966. (HTB 37) 

Zimmermann, P. 

Eine Einführung in die Theorie der 
Atomspektren 

91 S. mit Abb. 1976. Wv. 


Philosophie 


Enzyklopädie 
Philosophie und 

Wissenschaftstheorie in 3 Bänden 

Herausgegeben von Jürgen Mittelstraß. 
Rund 4000 Stichwörter auf etwa 
2 400 Seiten. Wv. 


Bunge, M. 

Epistemologie. 

Aktuelle Fragen der 
Wissenschaftstheorie 

Etwa 240 S. 1982. Aus dem Spanischen. Wv. 

Haas, G. 

Konstruktive Einführung in die 
formale Logik 

Etwa 200 S. 1982. Wv. 
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Kamlah, W. 

Philosophische Anthropologie. 
Sprachkritische Grundlegung und 
Ethik 

192S. 1973. (HTB238) 

Kamlah, W. 

Von der Sprache zur Vernunft. 
Philosophie und Wissenschaft in der 
neuzeitlichen Profanität 

230 S. 1975. Wv. 

Kamlah, W./P. Lorenzen 
Logische Propädeutik. 

Vorschule des vernünftigen Redens 

239 S. 2., verb. und erweiterte Aufl. 1973. 
(HTB227) 

Kanitscheider, B. 

Vom absoluten Raum zur 
dynamischen Geometrie 

139S. 1976. Wv. 

Leinfellner, W. 

Einführung in die Erkenntnis- und 
Wissenschaftstheorie 

227S. 3. Aufl. 1980. (HTB41) 

Lorenzen, P. 

Normative Logic and Ethics 

89 S. 1969. In englischer Sprache. (HTB236) 

Lorenzen, P./O. Schwemmer 
Konstruktive Kogik, Ethik und 
Wissenschaftstheorie 

331 S. mit Abb. 2., verbesserte Aufl. 1975. 
(HTB700) 

Mittelstaedt, P. 

Philosophische Probleme der 
modernen Physik 

227 S. 6., durchgesehene Aufl. 1981. 
(HTB50) 

Mittelstaedt, P. 

Die Sprache der Physik 

139S. 1972. Wv. 


Reihe: Grundlagen 
der exakten 
Naturwissenschaften 

Herausgegeben von Prof. Dr. Peter 
Mittelstaedt, Universität Köln. 

Band 1: 

Mittelstaedt, P./J. Pfarr (Hrsg.) 
Grundlagen der Quantentheorie 

159 S. 1980. Wv. 

Band 2: 

Strohmeyer, I. 

Transzententalphilosophische und 
physikalische Raum-Zeit-Lehre 

184S. 1980. Wv. 

Band 3: 

Mittelstaedt, P. 

Der Zeitbegriff in der Physik 

188S. 2., verbesserte und erweiterte Aufl. 
1980. Wv. 

Band 4: 

Pfarr, J. (Hrsg.) 

Protophysik und Relativitätstheorie 

240 S. 1981. Wv. 

Band 5: 

Neumann, H. (Hrsg.) 

Interpretations and Foundations of 
Quantum Theory 

144 S. 1981. In englischer Sprache. Wv. 


Chemie 


Grimmer, G. 

Biochemie 

376 S. mit Abb. 1969. (HTB187) 

Kaiser, R. 

Chromatographie in der Gasphase 
Band I: Gas-Chromatographie. 

220 S. mit 81 Abb. 2. Aufl. 1973. (HTB22) 
Band IV/2.Teil: Quantitative Auswertung. 
118S. mit Abb. 2., erweiterte Aufl. 1969. 
(HTB472) 
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Laidler, K. J. 

Reaktionskinetik 

Band I: Homogene Gasreaktionen. 

216S. mit Abb. 1970. Aus dem Englischen. 
(HTB290) 

Preuß, H. 

Quantentheoretische Chemie 
Band I: Die halbempirischen Regeln. 

94 S. mit 19 Abb. 1963. (HTB43) 

Band II: Der Übergang zur 
Wellenmechanik, die allgemeinen 
Rechenverfahren. 

238S. mit 19Abb. 1965. (HTB44) 

Band III: Wellenmechanische und 
methodische Ausgangspunkte. 

222 S. mit Abb. 1967. (HTB45) 

Riedel, L. 

Physikalische Chemie. 

Eine Einführung für Ingenieure 

406 S. 1974. Wv. 

Schmidt, M. 

Anorganische Chemie 

Band I: Hauptgruppenelemente. 

301 S. mit Abb. 1967. (HTB86) 

Band II: Übergangsmetalle. 221 S. mit Abb. 
1969. (HTB150) 


Medizin 


Forth, W./D. Henschler/ 

W. Rummel (Hrsg.) 

Allgemeine und spezielle 
Pharmakologie und Toxikologie 

Für Studenten der Medizin, 
Veterinärmedizin, Pharmazie, Chemie, 
Biologie sowie für Ärzte und Apotheker. 
3., überarbeitete Aufl. 1980.688 S. Über 400 
meist zweifarbige Abb. sowie mehr als 280 
Tabellen. Wv. 

Haas, H. 

Ursprung, Geschichte und Idee der 
Arzneimittelkunde 

(Reihe: Pharmakologie und Toxikologie, 
Band 1) 

178 S. 1981. Wv. 


Ingenieurwissenschaften 


Billet, R. 

Grundlagen der thermischen 
Flüssigkeitszerlegung 

150S. mit 50 Abb. 1962. (HTB29) 

Billet, R. 

Optimierung in der Rektifiziertechnik 
unter besonderer Berücksichtigung 
der Vakuumrektifikation 

129S. mit Abb. 1967. (HTB261) 

Billet, R. 

Trennkolonnen für die 
Verfahrenstechnik 

151 S. mit Abb. 1971. (HTB548) 

Böhm, H. 

Einführung in die Metallkunde 

236 S. mit Abb. 1968. (HTB196) 

Bosse, G. 

Grundlagen der Elektrotechnik 
Band I: Das elektrostatische Feld und der 
Gleichstrom. Unter Mitarbeit von W. 
Mecklenbräuker. 141 S. mit Abb. 1966. 
(HTB182) 

Band II: Das megnetische Feld und die 
elektromagnetische Induktion. Unter 
Mitarbeit von G. Wiesemann. 

154S. mit Abb. 2., überarbeitete Aufl. 1978. 
(HTB183) 

Band III: Wechselstromlehre, Vierpol- und 
Leitungstheorie. Unter Mitarbeit von A. 
Glaab. 

135S. 2., überarbeitete Aufl. 1978. 
(HTB184) 

Band IV: Drehstrom, Ausgleichsvorgänge 
in linearen Netzen. Unter Mitarbeit von J. 
Hagenauer. 

164S. mit Abb. 1973. (HTB185) 

Eschenauer, H./W. Schnell 
Elastizitätstheorie I. 

Grundlagen, Scheiben und Platten 

256 S. 1981. Wv. 
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Feldtkeller, E. 

Dielektrische und magnetische 
Materialeigenschaften 

Band I: Meßgrößen, Materialübersicht und 
statistische Eigenschaften. 

242S. mit Abb. 1973. (HTB485) 

Glaab, A./J. Hagenauer 
Übungen in Grundlagen der 
Elektrotechnik III, IV 

228S. mit Abb. 1973. (HTB780) 

Gross, D./W. Schnell 

Formel- und Aufgabensammlung zur 

Technischen Mechanik II. 

Elastostatik 

180S. mit Abb. 1980. (HTB792) 

Klein, W. 

Vierpoltheorie 

159S. mit Abb. 1972. Wv. 

Mahrenholtz, O. 

Analogrechnen in Maschinenbau und 
Mechanik 

208 S. mit Abb. 1968. (HTB154) 

Marguerre, K./H. Wölfel 
Technische Schwingungslehre. 
Lineare Schwingungen vielgliedriger 
Strukturen 

338 S. 1979. Wv. 

Marguerre, K./H.-T. Woernle 
Elastische Platten 

242 S. mit 125 Abb. 1975. Wv. 

Mesch, F. 

Meßtechnisches Praktikum 

Für Maschinenbauer und 
Verfahrentechniker. 

217 S. mit Abb. 3., überarbeitete Aufl. 1981. 
(HTB736) 

Pestei, E. 

Technische Mechanik 

Band I: Statik. 

Etwa 280 S. 2., neu bearb. und ergänzte 
Aufl. 1982. Wv. 

Pestei, E./J. Wittenburg 
Technische Mechanik 

Band 2: Festigkeitslehre. 

441 S. mit über 350 Abb. 1981. Wv. 


Piefke, G. 

Feldtheorie 

Band I: Maxwellsche Gleichungen, 
Elektrostatik, Wellengleichung, verlustlose 
Leitungen. 

264 S. Verbesserter Nachdruck 1977. 
(HTB771) 

Band II: Verlustbehaftete Leitungen, 
Grundlagen der Antennenabstrahlung, 
Einschwingvorgang. 

231 S. mit Abb. 1973. (HTB773) 

Band III: Beugungs- und Streuprobleme, 
Wellenausbreitung in anisotropen Medien. 
362 S. 1977. (HTB782) 

Sagirow, P. 

Satellitendynamik 

191 S. 1970. (HTB719) 

Schnell, W./D. Gross 

Formel- und Aufgabensammlung zur 

Technischen Mechanik I. Statik 

180S. mit Abb. 1979. (HTB791) 

Schnell, W./D. Gross 

Formel- und Aufgabensammlung zur 

Technischen Mechanik III. Kinetik 

180S. mit Abb. 1980. (HTB793) 

Stüwe, H. P. 

Einführung in die Werkstoffkunde 

197 S. mit Abb. 2., verbesserte Aufl. 1978. 
(HTB467) 

Stüwe, H. P./G. Vibrans 
Feinstrukturuntersuchungen in der 
Werkstoffkunde 

138S. mit Abb. 1974. Wv. 

Troost, A. 

Einführung in die allgemeine 
Werkstoffkunde metallischer 
Werkstoffe I 

507S. mit Abb. 1980. Wv. 

Waller, H./W. Krings 
Matrizenmethoden in der Maschinen- 
und Bauwerksdynamik 

377 S. mit 159 Abb. 1975. Wv. 

Wasserrab, Th. 

Gaselektronik 

Band I: Atomtheorie. 

223 S. mit Abb. 1971. (HTB742) 

Band II: Niederdruckentladungen, Technik 
der Gasentladungsventile. 

230S. mit Abb. 1972. (HTB769) 
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Wiesemann, G. 

Übungen in Grundlagen der 
Elektrotechnik II 

202 S. mit Abb. 1976. (HTB779) 

Wiesemann, G./W. Mecklenbräuker 
Übungen in Grundlagen der 
Elektrotechnik I 

179S. mit Abb. 1973. (HTB778) 

Wolff, I. 

Grundlagen und Anwendungen der 
Maxwellschen Theorie 
Band I: Mathematische Grundlagen, die 
Maxwellschen Gleichungen, Elektrostatik. 
236S. mit Abb. 1968. (HTB818) 

Band II: Strömungsfelder, Magnetfelder, 
quasistationäre Felder, Wellen. 

263S. mit Abb. 1970. (HTB731) 

Reihe: Theoretische und 
experimentelle Methoden der 
Regelungstechnik 

Herausgegeben von Gerhard Preßler, 
Hartmann & Braun, Frankfurt. 

Band 1: 

Preßler, G. 

Regelungstechnik 

348 S. mit 235 Abb. 3., überarbeitete Aufl. 
1967. (HTB63) 

Band 4: 

Klefenz, G. 

Die Regelung von Dampfkraftwerken 

Etwa 250 S. 3., überarbeitete Aufl. 1982. Wv. 

Band 8/9: 

Starkermann, R. 

Die harmonische Linearisierung 

Band II: 83 S. mit Abb. 1970. (HTB470) 

Band 10: 

Starkermann, R. 
Mehrgrößen-Regelsysteme 

Band I: 173S. mit Abb. 1974. Wv. 

Band 12: 

Schwarz, H. 

Optimale Regelung linearer Systeme 

242S. mit Abb. 1976. Wv. 


Band 13: 

Latzei, W. 

Regelung mit dem Prozeßrechner 
(DDC) 

213S. mit über 100Abb. 1977. Wv. 

Reihe: 

Gesellschaft, Recht, 

Wirtschaft 

Herausgegeben von Prof. Dr. Eduard 
Gaugier, Dr. Wolfgang Goedecke, Prof. Dr. 
Heinz König, Prof. Dr. Günther Wiese, Prof. 
Dr. Rudolf Wildenmann, Universität 
Mannheim. 

Band 1: 

Albert, H./M. C. Kemp/ 

W. Krelle/G. Menges/ 

W. Meyer 

ökonometrische Modelle und 

sozialwissenschaftliche 

Erkenntnisprogramme 

111S. 1978. Wv. 

Band 2: 

Bogaert, R./P. C. Hartmann 
Essays zur historischen Entwicklung 
des Bankensystems 

48 S. 1980. Wv. 

Band 3: 

Nerlove, M./S. Heiler/ 

H.-J. Lenz/B. Schips/ 

H. Garbers 

Problems of Time Series Analysis 

140S. 1980. Wv. 

Band 4: 

Aumann, R. J./J. C. Harsanyi/ 

W. Hildenbrand/M. Maschler/ 

M. A. Perles/J. Rosenmüller/ 

R. Selten/M. S. Shubik/ 

G. L. Thompson 

Essays in Game Theory and 

Mathematical Economics in Honor of 

Oskar Morgenstern 

200 S. 1981. In englischer Sprache. Wv. 

Band 5: 

Steinmann, H./G. Gäfgen/ 

W. Biomeyer 

Die Kosten der Mitbestimmung 

139S. 1981. Wv. 
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Band 6: 

Frisch, W./E. v. Caemmerer/ 

G. WUst/F. A. Mann/R. Fischer 
In Memoriam Konrad Duden 
Theorie und Praxis im 
Wirtschaftsrecht 
75 S. 1982. Wv. 

Band 7: 

Braun, W./K.-F. Ackermann/ 

E. Gaugler/H. Kossbiel/ 

G. Reber/W. Weber 
Verantwortliche PersonalfUhrung 

128S. 1982. Wv. 


Geographie/Geologie 


Ganssen, R. 

Grundsätze der Bodenbildung 

135S. mit 19 Zeichnungen und einer 
mehrfarbigen Tafel. 1965. (HTB327) 

Gierloff-Emden, H.-G./ 

H. Schroeder-Lanz 
Luftbildauswertung 
Band I: Grundlagen. 

154S. mit Abb. 1970. (HTB358) 


Wunderlich, H.-G. 

Einführung in die Geologie 
Band I: Exogene Dynamik. 

214 S. mit ca. 50 Abb. und 24 farbigen 
Bildern. 1968. (HTB340) 

Band II: Endogene Dynamik. 

231 S. mit Abb. und 16 farbigen Bildern. 
1968. (HTB341) 


B.I.-Hochschulatlanten 


Dietrich, G./J. Ulrich (Hrsg.) 

Atlas zur Ozeanographie 

76 S. 1968. (HTB307) 

SchmithUsen, J. (Hrsg.) 

Atlas zur Biogeographie 

80 S. 1976. (HTB303) 

Wagner, K. (Hrsg.) 

Atlas zur physischen Geographie 
(Orographie) 

59S. 1971. (HTB304) 


Kertz, W. 

Einführung in die Geophysik 
Band I: Erdkörper. 

232S. mit Abb. 1969. (HTB275) 

Band II: Obere Atmosphäre und 
Magnetosphäre. 

210S. mit Abb. 1971. (HTB535) 

Möller, F. 

Einführung in die Meteorologie 
Band I: Meteorologische 
Elementarphänomene. 

222 S. mit Abb. und 6 Farbtafeln. 1973. 
(HTB276) 

Band II: Komplexe meteorologische 
Phänomene. 

223 S. mit Abb. 1973. (HTB288) 

Wunderlich, H.-G. 

Bau der Erde. 

Geologie der Kontinente und Meere 
Band II: Asien, Australien. 

164 S., 16 S. farbige Abb. 1975. Wv. 
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